AD-A203  714 


57|f*  rn  r  rnr"-' 


SIMULATING  CLOTHING  AND  TEXTILE 
OPERATIONS  AT  THE  DEFENSE 
LOGISTICS  AGENCY 

VOLUME  I:  NARRATIVE  DESCRIPTION 

Report  DL703R1 


January  1989 


Robert  C.  Kline 
Christopher  H.  Hanks 


OTIC 


SELECTE 
JAN  2  5  198f 


Prepar«d  pursuant  to  Department  of  Defense  Contract  MDA903-86-C-0139. 
The  views  expressed  here  are  those  of  the  Logistics  Management  Institute  at 
the  time  of  issue  but  not  necessarily  those  of  the  Department  of  Defense. 
Permission  to  quote  or  reproduce  any  part  must  —  except  for  Government 
purposes  —  be  obtained  from  the  Logistics  Management  Institute. 


LOGISTICS  MANAGEMENT  INSTITUTE 
6400  Goldsboro  Road 
Bethesda,  Maryland  20817-5886 


DisriiJjiUTlONSTATEMENT  A 

Approved  for  public  relaose; 

L>;'’ir:;T.tioa  Unlimited 


PREFACE 


This  report  is  published  in  two  volumes.  Volume  I  is  a  narrative  description  of 
the  clothing  and  textiles  (C&T)  simulation  system,  which  includes  the  C&T 
simulation  itself,  a  "capture”  program  for  preparing  input  data,  and  an  analytic 
inventory  model  for  computing  variable  C&T  safety  levels. 

Volume  n  presents  a  listing  of  the  PC  SIMSCRIPT  n.5  source  code  for  each  of 
the  three  parts  of  the  system,  alphabetical  listings  and  brief  descriptions  of  each 
procedure,  and  outline  descriptions  of  the  flow  and  interactions  among  procedures. 
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Executive  Summary 

SIMULATING  CLOTHING  AND  TEXTILE  OPERATIONS 
AT  THE  DEFENSE  LOGISTICS  AGENCY 

0 

'  >To  help  evaluate  new  ideas  for  reducing  costs  and  improving  supply 
performance,  we  have  created  a  simulation  model  of  clothing  and  textile  (C&T) 
operations  at  the  Defense  Logistics  Agency  (DLA).  DLA’s  Clothing  and  Textiles 
Directorate  at  the  Defense  Personnel  Support  Center  in  Philadelphia  serves  as  the 
wholesale  manager  in  DoD  for  roughly  30,000  different  apparel  and  equipment 
items  worn  and  used  by  U.S.  Service  personnel.  The  C&T  Directorate  sells  and 
replenishes  more  than  $1.0  billion  worth  of  materiel  each  year  and  maintains  from 
$1.5  billion  to  $2.0  billion  in  inventory  at  depots  and  warehouses  worldwide. 

The  C&T  simulation  model  now  in  use  at  both  DLA  Headquarters  and  the  C&T 
Directorate  enables  inventory  managers  to  project  and  evaluate  the  potential  effects 
of  new  inventory  policies  and  operating  methods.  It  runs  on  DLA  Zenith  personal 
computers  (PCs)  and  operates  on  C&T  data  extracted  from  standard  DLA  Supply 
Control  Files.  It  provides  estimates  of  how  supply  performance,  inventory  levels, 
and  costs  are  affected  by  different  operating  policies  and  procedures. 

At  its  core,  the  model  incorporates  the  basic  operating  rules  and  architecture 
necessary  to  simulate  operations  and  interactions  with  customers  and  suppliers  as 
they  occur  at  any  DLA  Supply  Center.  For  the  C&T  application,  the  model  is 
specifically  tailored  to  reflect  unique  aspects  of  the  C&T  business,  such  as  multi-item 
procurement  groups  of  items  that  come  in  different  sizes,  program-based  estimates  of 
future  requirements,  phased  deliveries  from  suppliers,  and  the  key  C&T  mission  of 
providing  strong  supply  support  to  Recruit  Training  Centers.  (  u  - 

The  model  can  be  used  to  examine  a  variety  of  C&T  policy  options,  including 
variable  safety  levels,  matrix  delivery  schedules,  and  new  procxirement  cycle 
controls.  Because  it  is  menu-driven,  the  model  is  accessible  to  a  wide  class  of 
potential  users  —  managers  as  well  as  analysts.  Through  the  use  of  interactive 
queries  and  built-in  switches,  users  can  easily  modify  input  data  and  change  the 
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assumptions  in  a  model  run,  thereby  expanding  the  range  of  policy  questions  that 
can  be  examined  without  having  to  reprogram  the  model. 

As  the  first  in  what  could  eventually  become  a  family  of  PC-based  simulations 
of  DLA  supply  operations,  the  C&T  simulation  provides  a  tool  to  help  DLA  managers 
evaluate  new  C&T  policies  and  ideas  aimed  at  reducing  costs  and  improving  supply 
performance. 
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CHAPTER  1 


BACKGROUND 


INTRODUCTION 

The  clothing  and  textiles  (C&T)  simulation  is  a  personal  computer  (PC)*based 
model  of  inventory  management  in  the  Defense  Logistics  Agency’s  (DLA’s) 
wholesale  C&T  business.  Operating  through  its  C&T  Directorate  at  the  Defense 
Personnel  Support  Center  in  Philadelphia,  DLA  serves  as  the  wholesale  manager  in 
DoD  for  approximately  30,000  national  stock  numbers  (NSNs)  of  apparel  and 
equipment  items  worn  and  used  by  U.S.  Service  personnel. 

Because  different  sizes  of  the  same  item  have  different  NSNs,  the  C&T 
Directorate  manages  C&T  items  generically  by  procurement  grouping  code  (PGC). 
The  C&T  simulation  reflects  this  key  aspect  of  the  C&T  business  by  simulating  at 
the  PGC  level.  That  is,  in  a  single  run  the  model  generates  customer  ’’demands,” 
makes  supplier  ’’deliveries,”  and  replenishes  ’’inventory”  for  the  entire  set  of  items 
(all  NSNs)  in  a  P(jC.  A  PGC  is  processed  in  accordance  with  C&T  experience  and 
practice,  as  reflected  in  C&T  data. 

In  its  basic  operating  mode,  the  model  simulates  activity  for  a  single  PGC, 
processing  all  the  NSNs  in  the  PGC  simultaneously.  To  provide  system-level  results 
applicable  to  a  collection  of  different  PGCs,  the  model  can  process  PGCs 
sequentially,  one  at  a  time,  and  accxunulate  results.  Control  options  at  the 
beginning  of  a  run  allow  the  user  to  specify  whether  more  than  one  PGC  is  to  be 
processed  and  how  aggregate  results  are  to  be  acciimulated. 

The  model  is  designed  for  use  by  both  analysts  and  managers  to  test  new  ideas 
on  C&T  operations.  This  report  describes  how  the  model  works,  how  to  run  it,  and 
how  to  interpret  its  output. 

First-time  users  should  read  the  report  from  the  beginning.  Others  may  go 
directly  to  Chapters  for  step-by-step  instructions  on  how  to  run  the  model  — 
referring  to  other  chapters  as  necessary  for  a  review  of  model  mechanics. 
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In  ^his  chapter,  we  review  the  nature  of  the  C&T  business  and  the  background 
for  the  model’s  development.  We  address  the  question  ’’Why  simulation?”  and  look 
at  some  of  the  C&T  policy  questions  that  motivated  the  creation  of  the  model. 

In  Chapter  2,  we  describe  the  input  data  the  model  requires  to  operate.  These 
data  include  required  item-level  input  data  obtained  from  the  DLA  Standard 
Automated  Materiel  Management  System  (SAMMS),  as  well  as  control  data  and 
optional  input  data  supplied  interactively  by  the  user  prior  to  a  run.  Appendix  A 
shows  examples  of  input  files. 

In  Chapters,  we  describe  how  the  model  works.  We  start  with  a  general 
overview  and  follow  that  with  specifics  on  the  use  of  the  input  data,  operating  rules, 
order  of  operations,  and  probability  distributions  used  to  simulate  different  aspects 
of  the  C&T  business. 

In  Chapter  4,  we  describe  the  model’s  output  and  how  it  is  computed.  The 
output  of  every  run  includes  "trace”  information  that  contains  NSN-level  results,  a 
summary  report  at  the  PGC  level,  and  if  desired,  a  detailed  record  of  all  simulation 
events.  The  model  also  produces  an  Aggregate  PGC  Report,  which  can  summarize 
the  system-level  results  for  a  collection  of  PGCs  processed  sequentially  or 
accumulate  the  results  for  several  different  runs  on  the  same  PGC.  Graphic  output 
reports  are  also  described.  Chapter  4  also  covers  the  removal  of  the  effects  of  the 
warm-up  period,  the  determination  of  run  lengths  (related  to  sample  size),  and  the 
calculation  of  confidence  interval  estimates  for  backorders.  Appendix  B  contains 
examples  of  output  reports. 

In  Chapters,  we  present  verification  and  validation  results.  Verification 
involves  testing  model  results  to  ensure  that  internal  model  logic  and  calculations 
are  performing  as  intended.  Validation  is  a  comparison  of  model  projections  with 
real-world  C&T  data  on  backorders,  supply  availability  rates,  and  asset  positions  to 
see  how  well  the  model  is  able  to  reflect  real-world  behavior. 

In  Chapter  6,  we  give  step-by-step  instructions  for  running  the  model  on  a  DLA 
Zenith  PC.  The  model  requires  a  data  link  to  permit  downloading  of  SAMMS  data 
(Special  Supply  Control  Files  and  Management  Policy  Table  11  Reports)  from  a  DLA 
mainframe  computer  to  a  PC.  In  Chapter  6,  we  also  describe  how  to  transfer  input 
and  output  files  to  spreadsheet  format  (LOTUS  1-2-3)  for  further  analysis  if  desired. 
Appendix  C  describes  how  to  run  the  "capture”  program  for  preparing  input  files 
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from  downloaded  SAMMS  data.  Appendix  D  describes  an  analytic  variable  safety 
level  (VSL)  model  for  computing  VSL  values  prior  to  a  run.  Appendix  E  describes 
features  of  the  d3niamic  graphics  available  in  the  C&T  simulation  displays. 

In  Chapter  7,  we  offer  some  observations  and  suggestions  on  several  issues  that 
have  arisen  in  the  course  of  the  model’s  development.  We  discuss  weaknesses  and 
missing  information  in  the  input  data  available  from  SAMMS  and  ways  those  data 
might  be  improved  in  the  future.  We  address  possible  problems  arising  from  the  way 
new  C&T  delivery  schedules  for  controlling  leadtimes  are  being  programmed  into 
SAMMS  and  suggest  an  alternative  approach.  Finally,  we  describe  some  important 
areas  for  further  model  development  based  on  discussions  of  possible  applications  of 
the  model  in  the  future. 

The  C&T  simulation  model  is  programmed  in  PC  SIMSCRIPT  n.5,  a 
programming  language  specifically  designed  for  simulation  on  a  PC.  Volume  n  of 
this  report  contains  a  listing  of  the  model’s  PC  SIMSCRIPT  code,  descriptions  of 
what  each  SIMSCRIPT  routine  does,  and  an  outline  showing  how  the  different 
routines  in  the  model  relate  to  one  another. 

THE  C&T  BUSINESS 

Fundamentally,  C&T  operations  are  like  those  of  any  other  DoD  wholesale 
supplier:  customers  (retail-level  supply  outlets  at  military  installations  and  bases) 
order  materiel  from  C&T  wholesale  stocks  to  replenish  their  own  retail  stocks,  which 
they  use  to  serve  their  customers,  who  are  the  final  consumers  of  the  items.  As  their 
wholesale  stocks  are  drawn  down,  C&T  item  managers  monitor  asset  positions  (on 
hand  plus  on  order  minus  backorders)  and  decide  when  reorder  points  are  breached, 
whether  to  order  from  suppliers  to  replenish  their  inventories,  and  how  much  to 
order.  When  orders  are  placed,  they  are  for  replenishment  quantities  that  are  sized 
based  on  econonaic  and  procurement  considerations. 

The  system  thus  far  can  be  described  and  analyzed  with  standard 
mathematical  inventory  models. l  The  nature  of  C&T  items,  however,  and  the  way 


^Standard  mathematical  inventory  models  are  analytic  models  that,  in  one  form  or  another, 
solve  the  two  fundamental  problems  of  inventory  management;  when  to  order  (the  reorder  point) 
and  how  much  to  order  (the  order  quantity).  Such  models  usually  take  the  form  of  constrained 
optimization  models  that  minimize  ordering,  holding,  and  penalty  costs  for  a  system  of  items, 
subject  to  a  constraint  on  minimum  acceptable  supply  performance. 
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C&T  customers  and  suppliers  interact  with  the  C&T  Directorate,  combine  to  produce 
special  operating  characteristics  that  cannot  be  captured  with  standard  models. 
Some  other  way  to  analyze  C&T  operations  is  needed.  Simulation  is  a  natural  choice 
because  it  allows  incorporation  of  special  operating  features  without  requiring  the 
development  of  special  mathematics. 

The  special  features  distinguishing  C&T  operations  are  the  use  of  multi-item 
PGCs  for  management  of  sized  items  (e.g.,  shoes,  clothing,  outerwear);  the  use  of 
troop  strength  and  induction  forecasts  from  the  Services  as  the  basis  for  projecting 
demand  in  the  Program  Oriented  Item  (POI)  system;2  and  the  special  emphasis  the 
C&T  Directorate  places  on  providing  responsive  supply  support  to  Recruit  Training 
Centers. 

WHY  SIMULATION? 

The  C&T  Directorate’s  use  of  multi-item  PGCs  is  the  compelling  reason  for  the 
simulation  approach.  Within  the  C&T  commodity,  multi-item  PGCs  are  used  to 
manage  the  many  different  clothing  and  apparel  items  that  come  in  different  sizes. 
In  a  multi-item  PGC,  each  different  size  has  its  own  NSN,  reorder  point,  and 
procurement  cycle,  but  in  most  other  respects  the  entire  PGC  is  managed  as  a  single 
item.  For  example,  demand  is  forecasted  for  the  generic  item,  using  distributions 
("size  tariffs”)  to  allocate  demand  by  NSN.  Also,  in  a  multi-item  PGC,  when  any  one 
item  (size)  is  ordered  from  a  supplier,  other  items  (sizes)  can  and  often  will  be  ordered 
as  well  —  even  if  they  are  still  some  distance  from  their  reorder  points.  This 
reordering  policy  is  an  unavoidable  aspect  of  the  wholesale  C&T  business  because  it 
reflects  the  way  C&T  manufacturers  and  suppliers  generally  do  business:  They  deal 
in  large  orders,  and  large  orders  for  sized  items  usually  call  for  a  mix  of  sizes. 

The  multi-item  PGC  aspect  of  C&T  operations  prevents  the  use  of  standard 
mathematical  inventory  models  in  analyzing  even  simple  policy  alternatives.  Such 

2C&T  manages  about  30,000  different  items  (NSNs),  which  fall  into  four  separate  categories: 
POIs  —  about  8,500  items;  demand-based  items  [Quarterly  Forecasted  Demand  (QFD)]  -  about 
11,000  items;  Government-furnished  materiel  (GFM)  —  about  2,000  items;  and  new  and  numeric 
stockage  objective  (NSO)  items  —  about  9,000  items.  The  C&T  simulation  treats  POI  and  QFD  but 
not  GFM  or  new/NSO-type  items.  POI  and  QFD  comprise  approximately  two-thirds  of  the  total 
items  managed  by  C&T,  represent  the  bulk  of  C&Ts  dollar  volume  of  sales,  and  are  the  items  most 
affected  by  changes  in  DLA  inventory  management  policies.  The  GFM  program,  while  an 
important  part  of  C&T’s  business,  is  not  a  key  problem  area  according  to  C&T  Directorate 
personnel.  New/NSO-type  items,  while  also  important  and  certainly  a  source  of  potential  problems, 
are  by  nature  not  amenable  to  analysis  employing  demand-driven  inventory  models. 
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standard  models  assume  individual  items  are  ordered  only  when  at  or  near  their 
reorder  points  and  that  item  demand  patterns  are  independent  from  one  item  to  the 
next.  Neither  of  those  principles  holds  for  a  multi-item  PGC.  As  a  result,  standard 
analytic  models  cannot  reliably  project  how  changes  in  replenishment  and  ordering 
policies  will  affect  operations. 

C&T  POLICY  QUESTIONS 

Given  that  simulation  is  to  be  the  approach,  we  now  turn  to  the  particular  C&T 
policy  questions  of  interest.  The  issue  motivating  the  development  of  the  C&T 
simulation  is  the  question  of  variable  safety  levels. 

A  "safety  level”  is  the  extra  level  of  stock  for  an  item  —  beyond  that  required  to 
cover  average  demand  in  a  leadtime  —  that  protects  against  the  variations  that 
occur  about  the  average.  Currently,  the  C&T  Directorate  employs  a  fixed  safety 
level  in  which  each  NSN  in  a  PGC  is  assigned  a  safety  level  equal  to  expected 
demand  over  a  fixed  number  of  months.  The  number  of  months  depends  on  the 
category  of  the  PGC  (e.g.,  the  NSNs  in  PGCs  for  sized  items  issued  to  recruits  are 
generally  assigned  4.5  months  of  safety  level).  VSLs  are  safety  levels  that  are 
allowed  to  vary  from  item  to  item,  even  within  a  PGC,  depending  on  each  item’s 
characteristics  in  relation  to  other  items  in  the  system.  VSLs  are  used  by  DLA  and 
most  other  DoD  supply  organizations  to  maximize  supply  performance  for  a  given 
investment  in  stock  levels. 

VSLs  are  computed  using  mathematical  optimization  methods.  For  C&T 
operations,  the  question  is  whether  VSLs  can  improve  supply  performance  and 
reduce  inventory  investment  costs,  given  the  special  characteristics  of  the  C&T 
business.  The  optimization  techniques  generally  used  to  compute  VSLs  do  not 
account  for  multi-item  PGCs,  for  example,  nor  do  they  consider  the  effect  of 
incremental  deliveries.  The  first  job  for  the  C&T  simulation,  therefore,  is  to 
evaluate  what  would  happen  to  C&T  performance  and  costs  if  the  fixed  safety  levels 
currently  used  for  C&T  items  —  safety  levels  set  to  cover  a  fixed  number  of  months  of 
demand  —  were  to  be  replaced  with  VSLs  computed  essentially  as  they  are  for  other 
DLA  commodities.  (A  separate  LMI  briefing  book.  Variable  Safety  Levels  for 
Clothing  and  Textiles,  looks  at  this  question.) 

VSL  is  not  the  only  issue  the  C&T  simulation  can  address.  New  ordering  cost 
and  holding  cost  factors  and  new  minimum  and  maximum  cutoff  values  for 
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procurement  cycles  (order  quantities)  are  being  introduced  for  C&T  items.  New 
"matrix”  delivery  schemes  are  also  being  instituted  to  stabilize  C&T  leadtimes  and 
reduce  contractor/supplier  delinquencies.  Through  the  use  of  interactive  queries  and 
easy-to-modify  input  files,  users  can  experiment  with  the  simulation  to  determine 
the  potential  effects  of  these  new  policies. 

In  addition  to  various  features  for  current  C&T  policy  options,  the  simulation 
also  makes  it  easy  for  users  to  experiment  with  the  other  basic  factors  that  influence 
any  inventory  management  enterprise.  For  example,  switches  in  the  model  allow 
the  user  to  turn  on  and  adjust  demand  variability  and  leadtime  variability.  Users 
can  also  modify  the  input  data  for  the  model  and  many  of  the  model’s  control 
parameters  prior  to  a  run.  Together,  these  features  make  the  model  easy  to  use 
while  at  the  same  time  give  it  the  ability  to  address  a  variety  of  different  questions. 

Throughout,  a  major  goal  has  been  to  deliver  a  model  that  is  easy  to  use.  Once 
input  files  are  prepared  (and  edited  if  required  by  the  application),  a  model  run  is  set 
up  by  interactively  responding  to  a  short  list  of  simple  questions.  The  model  then 
runs  one  PGC  at  a  time  and  produces  a  standardized  set  of  summary  reports  that  can 
be  examined  to  see  how  alternative  management  policies  affect  supply  performance 
and  costs. 
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CHAPTER  2 


INPUT  DATA 


This  chapter  describes  the  information  needed  as  input  to  the  C&T  simulation 
prior  to  a  run.  Some  of  that  information  consists  of  data  from  external  sources 
required  prior  to  any  run;  some  is  control  information  supplied  interactively  by  the 
user;  and  some  is  optional  information  that  does  not  have  to  be  supplied  but  can  be  if 
the  application  requires  it.  The  main  focus  of  this  chapter  is  on  the  input  data  that 
are  required  from  external  sources.  Space  requirements  on  a  PC  hard  drive  for 
simulation  software  and  input  data  are  given  at  the  end  of  the  chapter. 

THREE  KINDS  OF  INPUT 

The  input  data  needed  to  run  the  C&T  simulation  fall  into  three  categories: 
required  input  data,  control  data,  and  optional  data.*  Required  input  data  are  the 
basic  data  about  the  items  to  be  simulated  that  must  be  present  in  two  input  files  on 
the  PC  hard  drive  before  a  run  can  begin.  These  required  data  are  obtained  from  two 
sources  in  the  OLA  SAMMS  system:  Special  Supply  Control  File  (SSCF)  reports  and 
Management  Policy  Table  11  (MPTOll)  reports.  The  SSCF  report  is  produced  by 
NSN  and  contains  item-specific  information;  the  MPTOll  report  is  produced  by  PGC 
and  contains  information  that  applies  to  all  the  NSNs  in  a  PGC  as  a  group. 

Control  input  data  consist  of  the  responses  a  user  makes  to  the  set  of 
interactive  queries  that  begin  a  run:  What  item(s)  are  to  be  simulated?  Do  you  want 
demand  variance?  Leadtime  variance?  Different  responses  to  these  and  other  start¬ 
up  queries  enable  a  user  to  control  and  change  how  the  model  operates  from  one  run 
to  the  next.  This  makes  it  possible  to  perform  different  analyses  without  having  to 
reprogram  the  model.  The  role  of  control  input  is  discussed  in  more  detail  in  the  next 
chapter. 

Optional  input  data  are  those  data  that  a  user  may  either  specify  or  defer  to 
default  values  that  are  provided  so  that  a  simulation  run  can  take  place.  In  general, 
the  more  flexible  a  model  is  in  terms  of  its  ability  to  answer  different  questions,  the 
more  complicated  it  is  to  set  up  a  run.  The  use  of  optional  inputs  in  the  C&T 
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simulation  provides  additional  flexibility  without  complicating  the  basic  model.  The 
choices  for  optional  input  are  discussed  in  more  detail  in  the  next  chapter. 


Once  a  user  has  selected  the  PGC  or  set  of  PGCs  to  be  simulated  and  arranged 
for  the  SSCF  and  MPTOll  reports  for  those  items  to  be  downloaded  to  a  PC,  the  C&T 
simulation  makes  it  easy  to  prepare,  input,  and  keep  track  of  all  three  kinds  of  data. 

For  SSCF  data,  the  required  input  file  is  prepared  by  running  a  prewritten, 
SIMSCRIPT  program  (incorporated  as  part  of  the  C&T  simulation  system)  that 
"captures”  what  is  needed  from  a  downloaded  SSCF  report  and  prepares  the  required 
file.  For  MPTOll  data,  the  required  input  file  consists  simply  of  downloaded 
MPTOll  reports,  which  are  read  by  a  routine  built  into  the  simulation  itself.  Both 
required  input  files  have  standard  names  (see  Chapters)  and  are  accessed  every 
time  the  model  is  run.  The  contents  of  both  files  are  also  included  in  output  as  part  of 
the  audit  trail  for  a  run. 

The  responses  a  user  makes  to  the  queries  that  begin  every  run  are  listed  prior 
to  the  run  and  in  output,  again  as  part  of  the  audit  trail. 

Optional  data  are  entered  through  the  use  of  five  optional  queries.  The  first 
optional  query  allows  the  use  of  VSLs  in  a  run.  Before  exercising  this  option,  a  file  of 
VSLs  must  be  constructed  with  the  C&T  VSL  model  (see  Appendix  D).  The  second 
and  third  optional  queries  allow  the  use  of  modified  input  files  that  can  contain 
"made-up”  SSCF  and  MPTOll  data,  for  users  who  want  to  experiment  without 
overwriting  actual  data.  The  fourth  optional  query  activates  an  Alternative 
Assumption  File  (see  Appendix  A,  Exhibit  A-4)  that  enables  users  to  change  various 
procurement  cycle  parameters,  controls  whether  input  data  is  reproduced  in  the 
output  file,  and  allows  users  to  shut  off  the  requisition-generation  logic  in  the 
model’s  demand-generation  process.  The  fifth  optional  query  allows  the  user  to  add 
graphic  output,  if  desired,  to  the  standard  output  tables  of  numerical  results. 

SPECIAL  SUPPLY  CONTROL  FILE  DATA 

The  SSCF  report  is  an  edited  printout  of  SAMMS  Supply  Control  File  data  for  a 
given  NSN.  The  collection  of  SSCF  reports  for  the  NSNs  in  a  given  PGC  (together 
with  PGC  information  in  MPTOll  Reports)  contains  the  required  information 
needed  to  simulate  C&T  inventory  management  for  the  PGC.  The  SSCF  data  are 
captured  from  the  header  section,  the  Demand/Retums  Trailer  (Trailer  E),  and  the 
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Program  Requirements  Trailer  (Trailer  U)  from  the  SSCF  report  for  each  NSN  in  the 
PGC.  Exhibit  A-1  in  Appendix  A  shows  an  example  of  the  Header  section  and 
Trailers  E  and  U  from  an  SSCF  printout.  The  data  elements  in  an  SSCF  Header 
section  are  referenced  in  Appendix  F-450  of  the  DLA  Manual  (DLAM)  4140.2, 
Supply  Operations  Manual,  Volume  H,  Part  3,  June  1982.  The  data  elements  in 
Trailers  E  and  U  are  defined  in  Appendices  F-191  and  F-149  of  DLAM  4140.2. 

To  prepare  the  required  SSCF  input  data  file  for  the  simulation,  SSCF  reports 
for  each  NSN  in  the  PGC  must  be  downloaded  from  a  SAMMS  mainframe  to  a  PC. 
SSCF  reports  are  normally  produced  in  hard  copy,  but  manual  entry  of  the  data  in 
SSCF  reports  is  not  practical.  For  downloading  to  a  PC,  it  is  most  convenient  to 
transmit  SSCF  reports  directly  to  the  PC  hard  disk  via  a  direct  telecommunications 
link  from  the  mainframe.  LMI  understands  that  such  links  are  available  both  in 
Philadelphia  and  in  the  DLA  Operations  Research  Office  (DORO)  in  Richmond, 
Virginia.  (Given  that  Management  Support  Offices  at  DLA  Supply  Centers  use 
SSCF  reports  and  that  DLA  has  been  acquiring  PCs,  it  makes  sense  for  DLA  to  have 
such  a  mainframe-to-PC  capability  even  without  the  C&T  application.)  Alternative 
approaches  are  to  write  SSCF  reports  to  tape  on  the  mainframe  and  use  an 
intermediate  device  [e.g.,  the  DLA  DMINS  (Distributed  Minicomuter  System)  or  a 
tape  reader]  to  read  the  tape  and  download  the  data  to  a  PC. 

Once  SSCF  reports  are  downloaded  to  the  PC,  a  capture  program  that  processes 
SSCF  reports  extracts  the  data  needed  from  each  SSCF  report  for  each  NSN  in  the 
PGC  and  formats  them  into  a  smaller  file  containing  only  the  data  the  simulation 
needs  to  process  the  PGC.  Exhibit  A-2  in  Appendix  A  is  an  example  of  what  a 
captured  SSCF  data  input  file  looks  like  for  a  PCJC  containing  three  NSNs. 

Most  of  the  data  elements  in  the  SSCF  input  file  prepared  by  the  capture 
program  are  identical  with  those  in  an  SSCF  report.  Moving  from  left  to  right  and 
top  to  bottom  in  a  captured  SSCF  input  file  (see  Exhibit  A-2  in  Appendix  A  for  an 
example),  data  elements  are  defined  as  follows: 

•  PROC.GR.CD:  Procurement  Grouping  Code  for  the  NSN  (see  DLAM 
4140.2,  Appendices  A-116  and  B-149). 

•  MAX. NSN:  Number  of  NSNs  in  the  PGC  (supplied  by  the  capture  program 
based  on  its  internal  count  as  it  processes  raw  SSCF  reports). 

•  ITEM  NAME:  Generic  description  of  the  item  (e.g.,  shirt,  man’s). 
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•  FSC:  Federal  Supply  Class  (four-digit  number), 

•  ICC:  Item  Category  Code  (possible  codes  are  1, 2,  B,  or  P;  1  =  QFD,  2  =  NSO, 
B = Insurance,  P  =  POI.  See  DLAM  4140.2,  Appendices  A-87  and  B-189), 

•  ADM.LT:  Administrative  leadtime  (in  days)  for  the  NSN  (see 
DLAM  4140.2,  Appendix  B-189). 

•  STANDARD. PRICE:  Price  charged  to  retail  customers  (see  DLAM  4140.2, 
Chapter  48). 

•  MAX. MONTH:  Number  of  months  of  forecasted  demand  (supplied  by  the 
capture  program,  based  on  its  internal  count  of  entries  in  the  Program 
Requirements  Trailer). 

•  NSN:  Ordinal  index  ofthe  list  ofNSNs  within  the  PGC. 

•  NUN:  National  Item  Identification  Number  (FSC  concatenated  with  NIIN 
is  the  NSN  for  the  item). 

•  PRO.LT:  Production  leadtime  (in  days)  for  the  NSN  (see  DLAM  4140.2, 
Appendix  B-189). 

•  VIP  (1  =Y):  Very  Important  Program  indicator  (1  =  yes)  (controls  whether 
requirements  are  computed  monthly  or  quarterly  in  SAMMS;  see  DLAM 
4140.2,  Appendix  B-188). 

•  FIX.SAFE:  Fixed  safety  level  in  months  of  demand  (applies  to  C&T  items). 

•  QFD:  Quarterly  forecasted  demand  (see  DLAM  4140.2,  Appendix  B-64). 

Note:  Some  items  in  the  POI  program  have  additional  demand  sources 
not  captured  in  POI  program  requirements  forecasts.  For  such  items,  this 
QFD  entry  shows  this  additional  forecasted  demand.  For  "pure”  QFD  items 
not  in  the  POI  program,  this  entry  contains  all  quarterly  forecasted 
demand. 

•  MAD:  Mean  absolute  deviation  (a  measure  of  monthly  or  quarterly  forecast 
error  in  demand  forecast;  see  DLAM  4140.2,  Appendices  F-450  and  D-185, 
and  Chapter  54). 

•  OWRMRP:  Other  War  Reserve  Materiel  Requirements  Protectable  (see 
DLAM  4140.2,  Appendix  B-181). 

•  ALPHA:  Regular  alpha  factor  (demand  forecast  control  factor;  see  DLAM 
4140.2,  Appendices  F-450,  F-262,  and  B-64).  The  alpha  factor  is  an 
extremely  important  parameter,  both  in  demand  forecasting  and  in  the 
calculation  of  stockage-level  requirements.  In  SAMMS,  the  alpha  factor  is 
used  to  smooth  demand  forecasts  for  QFD  items;  to  calculate  ?^D;  and  to 
convert  MAD  to  MADLT  (mean  absolute  deviation  in  leadtime),  which 
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measures  deviation  in  leadtime  demand.  The  C&T  simulation  uses  the 
alpha  factor  only  to  convert  MAD  to  MADLT.  It  does  so  following  the  MAD 
Multiplier  Formula  Table  in  the  SAMMS  documentation.  For  demand 
forecasts  and  MAD,  the  simulation  simply  uses  the  forecast  and  MAD 
values  from  SSCF  reports.  The  simulation  does  not  redo  the  smoothing 
already  done  to  obtain  those  data  elements. 

•  ARS:  Average  requisition  size  for  the  NSN  (computed  by  the  capture 
program  from  quantity  and  frequency  data  in  Demand/Retums  Trailer). 

Note:  ARS  refers  to  the  average  number  of  units  requested  on  the 
requisitions  submitted  to  the  C&T  inventory.  In  computing  the  ARS,  the 
capture  program  considers  only  demands  and  not  returns  listed  in  the 
Demand/Retums  Trailer.  Also,  for  items  indicated  to  have  high 
nonrecurring  demand,  only  the  "applicable  percentage”  of  demand 
(percentage  of  nonrecurring  demand  allowed  to  be  counted  as  recurring)  is 
used  in  computing  the  ARS. 

•  PER. RTC. DEM  AND:  Percent  Recruit  Training  Center  demand  [percent  of 
total  projected  demand  in  the  Program  Requirements  Trailer  that  is 
associated  with  RTC  program  identification  codes  (PICs);  computed  by  the 
capture  program]. 

Note:  The  POI  system  at  the  C&T  Directorate  utilizes  Service 
projections  of  inductions  and  troop  strengths  to  estimate  future  demands. 
In  making  that  estimate,  it  uses  PICs  (five-character  alphanumeric  codes) 
and  size  tariffs.  Service  forecasts  are  generated  by  PIC.  Demands  for 
different  sizes  (NSNs)  within  a  PIC  are  projected  by  applying  a  relative 
frequency  distribution  of  demand  by  size  —  the  size  tariff  for  the  PIC  —  to 
the  total  projected  demand  for  the  PIC.  Demand  projections  in  the  Program 
Requirements  Trailer  are  by  NSN  and,  therefore,  reflect  the  application  of 
the  PIC  size  tariff  implicitly.  Explicit  input  of  size  tariff  data,  therefore,  is 
not  required  by  the  C&T  simulation.  The  PICs  employed  by  C&T 
operations  for  the  POI  program  are  listed  in  Defense  Personnel  Support 
Center  (DPSC)-T  Local  Procedure  #R-28,  Volume  H,  DLAM  4140.2, 
Appendix  A- 130a.  The  capture  program  classifies  demand  from  "Initial 
Issue  —  Recruit”  PICs  as  RTC  demand.  Initial  issue  PICs  are  those  ending 
in  the  characters  AA,  AW,  or  GB.  For  example,  the  PIC  AOMAA 
corresponds  to  Army,  Male,  Active  (Recruit  Input).  References  for  the  POI 
program  and  the  PIC  system  are  Chapter  25  and  Appendices  B-51,  B-52, 
and  B-53  of  DLAM  4140.2.  For  "pure”  QFD  items  not  in  the  POI  program, 
the  RTC  demand  percentage  is  assumed  to  be  zero  in  the  C&T  simulation. 

•  CT  REQUIREMENTS  MATRIX:  6X6  matrices  (one  for  each  NSN  in  the 
PGC)  containing  POI  unit  demand  forecast  for  the  NSN,  summed  across  all 
PICs,  by  month  for  the  next  36  months;  assembled  by  the  capture  program 
from  data  in  the  SSCF  Program  Requirements  Trailer. 
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Note:  For  pure  QFD  items  not  in  the  POI  program,  there  is  no  C&T 
requirements  matrix  in  the  SSCF  input  file.  Forecasted  requirements  for 
pure  QFD  items  appear  under  the  QFD  data  element  listed  earlier. 

•  END.OF.PGC:  Marker  indicating  end  of  SSCF  data  for  NSNs  in  indicated 
PGC;  supplied  by  the  capture  program. 

•  PGC  QRQMT:  Average  projected  quarterly  requirement  for  entire  PGC 
from  first  year  of  program,  computed  by  the  capture  program  from  the 
Program  Requirements  Trailer. 

•  PGC  QD:  Historic  average  quarterly  demand  for  PGC,  computed  by  the 
capture  program  from  the  Demand/Returns  Trailer. 

•  %AlR:  Ratio  of  actual  to  projected  demand  (ratio  of  PGC  QD  to  PGC 
QRQMT)  expressed  as  percentage;  computed  by  the  capture  program. 

The  simulation  processes  one  PGC  at  a  time.  When  a  collection  of  PGCs  is  to  be 
processed  for  system-level  analysis,  the  simulation  processes  each  PGC  separately 
and  accmnulates  results.  The  capture  program  can  be  used  to  prepare  a  single  input 
file  that  the  simulation  can  use  for  different  PGCs.  To  prepare  that  file,  the  user 
must  group  SSCF  reports  (which  are  prepared  by  NSN)  together  by  PGC  for 
processing  by  the  capture  program.  When  requesting  the  downloading  of  SSCF 
reports,  a  user  should  always  request  NSNs  grouped  by  PGC.  (Part  of  whatever 
standard  procedure  DLA  develops  to  move  SSCF  data  to  a  PC  should  include  the 
capability  to  request  SSCF  data  by  PGC  so  that  SSCF  reports  by  NSN  are 
automatically  grouped  together  by  PGC  in  the  downloaded  file.)  From  a  set  of  SSCF 
reports  grouped  by  PGC,  the  capture  program  builds  the  required  SSCF  input  file  by 
PGC.  Then,  when  a  collection  of  PGCs  is  processed  sequentially,  the  simulation  will 
search  the  SSCF  file  created  by  the  capture  program  for  each  PGC  to  find  its 
associated  NSNs. 

MANAGEMENT  POLICY  TABLE  1 1  DATA 

A  Management  Policy  Table  11  (MPTOll)  —  also  referred  to  as  the 
Procurement  Group  Table  —  exists  for  every  PGC  managed  by  the  C&T  Directorate 
(POI  and  QFD  items).  The  table  begins  with  a  header  section  containing 
quantitative  management  parameters  for  the  PGC  as  a  group  of  similar  items, 
followed  by  a  listing  of  the  individual  items  (NSNs)  in  the  PGC.  The  C&T 
simulation  requires  only  header  data  from  MPTOll;  all  required  NSN-level 
information  for  the  PGC  comes  from  SSCF  reports  as  described  earlier.  Exhibit  A-3 
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in  Appendix  A  contains  an  example  of  an  MPTOll.  The  data  elements  are 
referenced  in  DLAM  4140.2,  Appendix  F-116.1 

To  prepare  the  required  MPTOll  input  data  file  for  a  run,  a  user  must  arrange 
for  MPTOlls  for  the  PGC  (or  PGCs)  in  question  to  be  downloaded  from  a  SAMMS 
mainframe  to  the  PC,  just  as  is  the  case  for  SSCF  reports.  All  the  MPTOlls  should 
be  stored  in  the  file  ’'C:\SIMVDLA\MPT011.DAT.”  Once  they  have  been  downloaded 
to  the  PC  hard  drive,  a  routine  built  into  the  C&T  simulation  extracts  the  data  that 
are  needed  for  the  simulation  to  run. 

Moving  from  left  to  right  and  top  to  bottom  in  an  MPTOll  input  file  (see 
Exhibit  A-3  in  Appendix  A),  MPTOll  data  elements  used  by  the  C&T  simulation  are 
as  follows: 

•  PROCUREMENT  GROUP  CODE:  VGC. 

•  MINIMUM  PROC  CYCLE:  The  smallest  procurement  cycle  (order 
quantity  expressed  in  months  of  demand)  among  the  (possibly)  different 
procurement  cycles  for  the  different  NSNs  in  the  PGC. 

•  DEL  %:  Delivery  percentages  for  the  PGC  —  up  to  12  entries  —  reflecting 
the  number  of  months  over  which  a  supplier  is  to  deliver  (the  delivery 
period)  and  the  percentage  of  the  total  order  to  be  delivered  in  each  of  those 
months. 

•  METHOD  OF  DELIVERY :  1,  2,  3,  or  4  —  reflecting  one  of  four  possible 
delivery  schemes  describing  how  different  NSNs  within  the  PGC  are  to  be 
delivered  over  the  delivery  period  [see  DLAM  4140.2,  Chapter  26,  Delivery 
Schedules  —  (Working  Copy)]. 

•  PGC  FLRST  DELIVERY  DAYS:  Number  of  days  to  first  delivery  for  the 
PGC.  (The  first  delivery  for  a  PGC  is  assumed  to  occur  at  the  end  of  the  first 
month  in  the  delivery  period.) 


lAs  of  September  1988,  the  format  and  content  of  the  header  information  in  MPTOl  1  for  C&T 
PGCs  has  been  revised  to  allow  inclusion  of  parameters  reflecting  the  new  matrix  delivery 
scheduling  policy  for  the  C&T  Directorate.  The  C&T  simulation  requires  MPTOlls  that  incorporate 
the  new  format  and  content.  OLA  documentation  of  the  new  MPTOl  1  format  and  content  appears  in 
a  revised  version  of  Appendix  F- 116  of  DLAM  4140.2.  DLA  documentation  of  new  C&T  delivery 
scheduling  policies  appears  in  a  new  chapter  of  DLAM  4140.2,  Chapter  26,  Delivery  Schedules, 
Volume II,  Parti.  Working  copy  versions  of  both  documents  are  available  from  the  Defense 
Systems  Automation  Center  (DSAC),  Columbus,  Ohio. 
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•  XYZ  ITEM  PERCENT:  Cutoff  values  for  NSN  order  quantity  as 
percentage  of  total  PGC  order  quantity,  used  to  classify  items  as  X,  Y,  or  Z 
items  in  delivery  method. 

Note:  Two  percentage  values  are  listed  to  define  the  X,  Y,  and  Z  items. 
X  items  are  items  whose  order  quantity  is  greater  than  or  equal  to  the  first 
value.  Z  items  are  those  whose  order  quantity  is  less  than  or  equal  to  the 
second  value.  All  remaining  items  are  Y  items. 

In  addition  to  the  PGC-level  header  information  described  above,  the  MPTOll 
lists  all  the  NSNs  in  the  PGC.  The  simulation  reads  that  list  but  does  not  use  the 
information  in  any  of  its  processing.  The  simulation  associates  NSNs  with  a  PGC 
based  on  the  PGC  data  element  that  appears  in  the  SSCF  data  for  each  NSN.  One 
way  for  DLA  to  automate  the  preparation  of  raw  SSCF  data  for  the  simulation  would 
be  to  arrange  for  the  generation  of  SSCF  reports  for  NSNs  in  an  MPTOll.  This 
would  automatically  produce  SSCF  reports  grouped  by  PGC. 

The  role  of  MPTOll  information  in  simulating  C&T  management  of  PGCs  is 
discussed  in  the  next  chapter. 

SPACE  REQUIREMENTS 

The  space  requirements  of  the  C&T  simulation  system  on  the  hard  disk  of  a  PC 
are  for  programs  and  data.  The  programs  in  the  system  require  a  total  of 
approximately  4  megabytes  of  hard  disk  space;  the  SIMSCRIPT  software  requires 
2  megabytes  (including  the  swap  file  of  the  virtual  memory),  the  simulation  program 
requires  1.3  megabytes,  the  capture  program  requires  0.4  megabytes,  and  the  VSL 
model  requires  0.3  megabytes.  Space  requirements  for  data  are  driven  primarily  by 
SSCF  data.  Before  capture,  the  raw  SAMMS  SSCF  file  for  one  NSN  requires  a 
maximum  of  50  kilobytes  (50,000  bytes)  of  space.  Pure  QFD  NSNs  require  about 
15,000  bytes  per  NSN.  After  capture,  a  maximum  of  1  kilobyte  per  NSN  is  required, 
and  the  raw  SSCF  file  can  be  deleted  from  the  PC  hard  disk. 
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CHAPTERS 


HOW  THE  CAT  SIMULATION  WORKS 


OVERVIEW 

Wholesale  inventory  management  has  four  aspects:  forecasting  requirements, 
controlling  inventory,  responding  to  customer  demand,  and  dealing  with  suppliers. 
Everything  that  happens  in  an  inventory  management  enterprise  can  be  understood 
in  terms  of  these  four  activities  and  the  way  they  interact.  A  way  to  understand  how 
the  C&T  simulation  works  is  to  see  how  it  handles  these  activities. 

In  its  treatment  of  the  four  aspects  of  inventory  management,  the  simulation 
captures  the  key  features  of  C&T  operations  that  must  be  considered  when  new 
policies  are  being  reviewed.  However,  because  it  is  a  model  —  that  is,  a  simplified 
idealization  of  a  complex  activity  in  the  real  world  >  the  simulation  does  not  capture 
everything  that  goes  on  in  C&T  operations.  It  is  sometimes  tempting  to  forget  that 
fact  and  treat  the  simulation  as  though  it  were  a  miniaturized  version  of  the  entire 
C&T  enterprise,  suppliers  and  customers  included,  sitting  inside  a  large  box,  busily 
replicating  everything  that  goes  on  in  the  world.  It  is  important  to  resist  such  a 
temptation.  The  simulation  is  a  computer  model  that  does  what  it  does  by 
manipulating  information  and  data  in  a  sequence  of  operations  within  a  computer. 
It  cannot  go  beyond  what  its  data,  algorithms,  distributions,  and  assumptions  allow 
it  to  do. 

As  an  example,  no  data  are  yet  available  to  show  how  C&T  suppliers  will  react 
to  the  new  matrix  delivery  schedules  being  introduced.  In  the  real  world,  suppliers 
will  react  and  leadtime  variabilities  will  change  in  some  way.  If  we  had  a  miniature 
version  of  the  real  C&T  world  in  a  box,  we  could  lift  the  lid  and  see  whether  the  new 
matrix  schedules  result  in  suppliers  delivering  more  orders  on  time.  With  the 
simulation,  the  best  we  can  do  is  adjust  the  distribution  that  controls  when  deliveries 
occur  and  then  measure  the  effects  if  delivery  performance  improves. 

Although  the  simulation  cannot  address  all  possible  questions,  it  can  address  a 
large  number  of  them.  This  makes  it  important,  when  deciding  whether  the  model 
can  be  applied  to  a  given  problem,  to  have  a  clear  view  of  what  is  in  the  model  and 
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what  is  not.  This  chapter  provides  that  information.  It  describes  how  requirements 
forecasts  are  generated,  how  inventory  is  controlled,  how  customer  demand  is 
modeled,  and  how  supplier  responsiveness  is  simulated.  Potential  users  can  see 
where  special  attention  has  been  paid,  how  input  data  are  used,  and  where  technical 
emphasis  has  been  placed. 

The  C&T  model  is  a  discrete  event  simulation  model;  that  is,  it  employs 
variables  whose  values  change  a  finite  number  of  times  over  the  course  of  a  run, 
based  on  the  rules,  procedures,  calculations,  and  probability  distributions  built  into 
the  model.  1 

The  basic  unit  of  simulation  is  the  PGC,  whether  multi-item  or  single  item. 
Each  time  the  simulation  runs,  it  simulates  what  happens  over  time  to  a  single  PGC 
in  the  C&T  inventory  management  process.  In  general,  the  following  things 
"happen”  to  a  PGC:  requirements  forecasts  are  made;  stock  levels,  reorder  points, 
and  order  quantities  for  each  NSN  in  the  PGC  are  set  and  periodically  recomputed; 
stock  is  drawn  down  by  customer  demand;  reorder  points  are  reviewed; 
replenishment  orders  are  placed  with  suppliers;  and  stock  is  replenished  when 
replenishment  orders  are  delivered.  In  the  simulation,  all  of  those  processes  are 
modeled  by  assigning  values  to  variables  and  then  allowing  those  values  to  change 
according  to  the  schedules,  rules,  and  probability  distributions  that  constitute  the 
model. 

FORECASTING  REQUIREMENTS 

Requirements  forecasts  are  projections  of  future  demand.  In  the  real-world 
C&T  system,  requirements  are  forecasted  and  updated  for  each  NSN  in  SAMMS  on  a 
monthly  or  quarterly  basis  and  stored  in  Supply  Control  Files.  The  simulation, 
however,  does  not  have  new  requirements  forecasts  being  presented  to  it  from 
external  sources  over  time.  It  must  generate  its  own  "new”  requirements  forecasts 
based  on  one  single  instance  of  a  requirements  forecast  as  recorded  in  the  Program 
Requirements  Trailer  of  an  SSCF  report.  As  simulated  time  proceeds,  the 


t  Discrete  event  simulation  contrasts  with  continuous  simulation.  In  a  continuous 
simulation,  differential  equations  are  used  to  describe  how  variables  change  over  time,  and 
integrations  are  performed  to  solve  for  particular  values  after  intervals  of  time  have  "elapsed."  A 
continuous  simulation  of  C&T  operations  was  developed  by  DPSC/Operations  Research  and 
Economic  Analysis  Office  in  conjunction  with  work  on  the  new  C&T  matrix  delivery  schedules. 
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simulation  must  generate  a  new  requirements  forecast  for  each  NSN  in  the  PGC  it  is 
processing.  It  does  this  for  POI  items  as  follows. 

At  the  beginning  of  a  run,  input  data  from  the  Program  Requirements  Trailer 
for  a  POI  item  provide  the  simulation  with  a  statement  of  projected  program 
requirements  for  the  NSN  for  up  to  36  months  into  the  future.  The  simulation 
computes  the  average  value  and  standard  deviation  of  those  36  monthly  data  points 
and  constructs  a  normal  distribution  with  that  mean  and  standard  deviation.  It  then 
draws  60  times  from  that  normal  distribution  to  build  a  (1X60)  array  representing 
projected  monthly  demand  requirements  for  the  next  5  years  of  simulated  time.  As 
simulated  time  proceeds,  new  draws  are  made  and  the  requirements  array  is 
updated  periodically  so  that  the  simulation  always  has  access  to  a  projected  monthly 
requirements  forecast  extending  5  years  into  the  future.  If  the  POI  item  has  a 
nonzero  QFD  value  in  its  input  data  —  indicating  the  item  has  demand  sources  not 
incorporated  in  the  POI  program  —  the  QFD  value  is  divided  by  three  and  each 
monthly  POI  forecast  is  increased  by  the  QFD/3  amount  whenever  the  requirements 
array  is  used.  The  forecast  sum  is  referred  to  as  Fi  in  this  chapter. 

Part  of  what  makes  POI  items  unique  in  SAMMS  is  that  forecasted 
requirements  are  based  on  future  program  forecasts  rather  than  historical  demand. 
Quantitative  levels  (i.e.,  reorder  points,  order  quantities,  and  acquisition  objectives) 
are  set  in  terms  of  'Months  of  demand.”  For  POI  items,  therefore,  the  simulation 
needs  the  ’’rolling”  5-year  requirements  forecasting  array  described  above  to  be  able 
to  compute  and  periodically  update  quantitative  levels  in  the  same  way  they  are 
updated  in  SAMMS.  A  requirements  array  extending  5  years  into  the  future  is  long 
enough  to  accommodate  the  range  of  leadtimes  and  procurement  cycles  that  occurs 
in  the  C&T  program. 

The  procedure  described  for  simulating  the  forecasting  of  POI  requirements 
yields  forecasts  that  are  like  the  input  forecast  in  terms  of  mean  and  standard 
deviation.  The  simulated  forecasts  will  not  reflect  a  pattern  of  steadily  increasing  or 
decreasing  demand,  however,  if  such  a  trend  is  present.  This  complicates  the 
problem  of  using  the  simulation  to  analyze  the  effects  of  trends.  In  the  real  world,  if 
a  demand  trend  holds  up  over  several  forecasts,  the  C&T  system  will  adapt  with 
steadily  increasing  or  decreasing  inventory  control  levels.  To  produce  the  same 
effect  in  the  simulation,  it  would  be  necessary  to  modify  the  simulation  to  either  do 
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multiple  runs  on  a  single  36-month  forecast  or  build  in  a  trend- inducing  factor  to 
cause  requirements  to  rise  over  time  in  the  rolling  requirements  array. 

The  preceding  discussion  applies  to  a  POI  item.  For  a  pure  QFD  item,  there  is 
no  draw  from  a  normal  distribution  to  obtain  the  monthly  forecast.  The  forecast  for 
every  future  month  is  simply  the  quarterly  forecasted  demand  value  from  the  SSCF 
report  divided  by  three.  Just  as  the  procedure  for  POI  items  was  designed  to  be 
consistent  with  SAMMS  processing,  this  procedure  for  QFD  items  is  consistent  with 
the  way  pure  QFD  items  are  treated  in  SAMMS.  In  SAMMS,  when  quantitative 
levels  are  computed  for  pure  QFD  items,  the  QFD  value  in  the  Supply  Control  File  is 
treated  as  the  underlying,  stationary  demand  rate  for  the  item  for  all  future  time. 
(This  assumption  is  standard  in  inventory  control  systems  in  which  quantitative 
levels  are  periodically  updated  and,  in  fact,  is  the  reasonable  thing  to  do.  Even 
though  a  new  set  of  quantitative  levels  will  be  computed  a  month  or  a  quarter  later 
using  new  data,  the  QFD  value  at  the  time  of  any  given  computation  represents  the 
current  best  estimate  of  what  the  demand  rate  will  be  in  the  future.) 

The  next  section  describes  how  requirements  forecasts  are  used  in  setting 
quantitative  levels.  In  the  section  after  next,  we  will  see  how  requirements  forecasts 
also  affect  how  customer  demands  are  generated. 

CONTROLLING  INVENTORY 

In  this  section,  we  define  how  quantitative  levels  —  reorder  points,  order 
quantities,  and  acquisition  objectives  —  are  set  and  used  in  the  C&T  simulation. 
Throughout,  the  procedures  described  are  identical  to  the  procedures  used  in 
SAMMS  for  controlling  C&T  inventory. 

An  inventory  system  is  a  system  in  which  stocks  are  held,  issued,  and 
replenished.  The  behavior  of  inventory  in  such  a  system  is  controlled  by  the  rules 
governing  when  replenishment  orders  will  be  placed  and  how  much  they  will  be  for. 
The  C&T  system  and  the  simulation  both  employ  a  reorder  point,  order  quantity, 
order-up-to-an-acquisition-objective  methodology  to  decide  when  orders  will  be 
placed  and  how  much  they  will  be  for. 

Reorder  Point 

In  the  C&T  simulation,  each  NSN  within  a  PGC  is  assigned  a  reorder 
point  —  either  on  a  monthly  or  quarterly  basis  depending  on  whether  the  item  is  a 
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VIP  item  or  not.  For  NSNs  with  POI  requirements,  the  reorder  point  (ROP)  is  the 
number  defined  as  follows: 

ROP  Period  t  p  ^ 

ROP  =  X  F.  +  JxSL  +  OWRMRP, 

i*l  ial 

where  Fi  denotes  the  forecasted  program  requirement  in  month  (i)  from  the  "rolling” 
60-month  requirements  array  described  in  the  previous  section,  the  ROP  period  is 
the  procurement  leadtime  in  months,  SL  denotes  the  safety  level  in  months  for  the 
item,  and  OWRMRP  is  the  Other  War  Reserve  Materiel  Requirements  Protectable. 
(OWRMP  is  a  DoD  term  used  to  denote  a  category  of  wholesale-level  war  reserve 
stocks.  The  C&T  Directorate  policy  is  to  include  OWRMRP  in  C&T  reorder  points.) 

For  pure  QFD  itezns,  the  reorder  point  is  deHned  as  follows: 

ROP  =  X  ROP  Period  +  ^  SL  +  OWRMRP  t^q.  3-2] 

Normally,  the  meaning  of  a  procurement  leadtime  is  well-defined  in  the 
discussion  of  a  reorder  point.  A  procurement  leadtime  represents  the  sum  of 
administrative  leadtime  and  production  leadtime  (ALT+PLT),  and  both  ALT  and 
PLT  are  input  data  elements  from  an  SSCF  report.  The  new  matrix  delivery  policies 
being  introduced  at  the  C&T  Directorate,  however,  affect  how  PLTs  will  be  defined 
for  purposes  of  setting  reorder  points.  Because  the  matrix  delivery  policies  are  new, 
Supply  Control  Files  do  not  yet  reflect  the  new  PLTs.  To  make  the  simulation 
compatible  with  the  new  delivery  policies,  we  have  incorporated  a  different 
procedure  for  determining  what  the  PLT  is  for  an  item  (NSN).  Rather  than  simply 
reading  the  PLT  from  the  SSCF  input  data,  the  simulation  computes  a  PLT  from 
data  in  the  MPTOll  for  the  PGC  containing  the  NSN  since  the  information  defining 
new  C&T  delivery  schedules  has  been  incorporated  into  the  MPTOlls. 

For  purposes  of  setting  reorder  points,  PLTs  are  derived  from  MPTOll  input 
data  as  follows:  The  order  quantity  for  the  NSN  (defined  later  in  this  section)  is 
compared  with  the  sum  of  the  order  quantities  for  all  NSNs  in  the  PGC.  Depending 
on  the  NSN’s  order  quantity  percentage  relative  to  the  total  PGC  order  quantity,  the 
NSN  is  classified  as  an  X,  Y,  or  Z  item  according  to  the  XYZ  item  percent  cutoff 
values  in  the  MPTOll  input  data.  The  delivery  method  for  the  PGC  containing  the 
NSN  is  also  obtained  from  the  MPTOll  input,  as  is  the  niunber  of  days  to  first 
delivery  for  the  PGC.  The  simulation  counts  the  number  of  consecutive  nonzero 
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delivery  percentages  in  the  MPTOll  data  to  determine  the  number  of  months  over 
which  deliveries  are  to  be  made.  That  number  of  months  is  referred  to  as  the 
delivery  period  and  represents  the  number  of  delivery  increments.  With  that 
information,  the  simulation  computes  a  PLT  in  days  for  the  NSN  as  the  following 
sum: 

PLT  =  #ofdays  to  first  delivery  +  (#  of  delivery  increments  X  30)  X  DPF, 

where  DPF  denotes  a  delivery  period  factor  whose  value  depends  on  whether  the 
item  is  an  X,  Y,  or  Z  item  and  what  the  method  of  delivery  is.  The  particular  values 
for  DPF  that  are  programmed  in  the  model  are  those  described  in  Chapter  26  of 
DLAM  4140.2,  Delivery  Schedules  (Working  Copy),  available  from  DSAC.  As  an 
example,  for  an  Xitem  under  Method  of  Delivery  1,  the  DPF  is  one-third.  With  a 
6-month  delivery  period,  this  makes  the  second  term  in  Equation  3-2  equal  to 
60  days  (2  months).  The  idea  of  the  DPF  is  to  set  the  PLT  so  that  it  falls  at  a 
reasonable  point  within  the  delivery  period  for  an  item  whose  order  quantity  is 
delivered  in  increments  over  several  months. 

The  most  important  aspect  of  this  way  of  defining  the  reorder  point  PLT  is  that 
both  in  the  real  world  and  in  the  simulation,  PLTs  will  be  based  on  a  planned 
schedule  rather  than  on  actual  leadtimes  achieved  by  suppliers.  This  policy  reflects 
a  deliberate  DLA  decision  to  exercise  greater  control  over  C&T  leadtimes  and  their 
effect  on  C&T  stockage  levels.  The  new  delivery  schedules  are  supposed  to  better 
reflect  what  manufacturers  and  suppliers  can  actually  deliver.  If  this  holds  true, 
policy-based  PLTs  and  actual  PLTs  will  not  be  all  that  different.  As  discussed 
earlier,  however,  the  simulation  cannot  be  used  to  see  whether  suppliers  will  indeed 
do  a  better  job  of  meeting  the  new  schedules.  Data  on  that  subject  are  not  available, 
and  the  simulation  cannot  be  'Tjootstrapped”  into  answering  the  question  without 
such  data. 

Eventually,  historical  PLT  values  in  C&T  Supply  Control  Files  will  be  replaced 
or  augmented  by  schedule-based  PLTs.  (It  is  important  to  record  and  save  historical 
PLTs  somewhere  in  SAMMS  in  order  to  monitor  supplier  response  to  the  new 
schedules  and  to  provide  the  data  needed  for  leadtime  variability  analyses.)  When 
the  new  PLTs  are  incorporated  into  Supply  Control  Files,  it  will  be  possible,  with 
some  reprogramming,  to  revert  to  the  use  of  SSCF  PLT  values  in  the  simulation  if 
DLA  so  desires.  MPTOll  information  can  be  used,  however,  as  long  as  PLTs  for 
reorder  points  are  based  on  planned  delivery  schedules.  Used  in  this  way,  MPTOlls 
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have  the  added  advantage  of  providing  additional  flexibility  for  applications.  In 
particular,  before  running  the  model,  users  can  change  MPTOll  input  data  through 
the  use  of  an  alternative  MFTOll  input  file,  making  it  possible  to  experiment  with 
different  delivery  methods  for  multi-item  PGCs. 

A  final  point  on  the  new  delivery  schedules:  separate  from  their  role  in  the 
setting  of  PLTs  for  reorder  points,  they  will  also  influence  how  deliveries  actually 
occur  —  both  in  the  real  world  and  in  the  simulation.  In  particular,  both  in  the  real 
world  and  the  simulation,  the  time  to  delivery  for  a  given  item  after  it  has  been 
ordered  will  generally  be  different  from  the  leadtime  used  to  set  its  reorder  point. 
Some  of  this  difference  between  reorder-point  leadtimes  and  actual  leadtimes  is 
inevitable,  of  course,  given  the  ever-present  variability  in  leadtimes.  However,  the 
normal  differences  may  be  exacerbated  by  the  way  in  which  new  delivery  schedule 
logic  is  being  implemented  in  SAMMS.  In  the  next  section,  we  describe  the  way 
delivery  schedules  are  used  to  generate  supplier  deliveries.  We  include  a  discussion 
of  the  role  and  effects  of  the  "needs  test,”  and  how  it  has  been  incorporated  into  the 
model.  In  Chapter  7,  we  present  and  discuss  some  of  the  potential  problems  that  may 
arise  from  delivery  schedule  implementation.  At  this  stage,  having  described  how 
PLTs  are  determined  for  purposes  of  setting  C&T  reorder  points,  we  return  to  the 
general  discussion  of  reorder  points  and  quantitative  levels. 

In  logical  terms,  the  reorder  point  is  equal  to  the  average  demand  in  a  leadtime 
plus  safety  level  and  the  protectable  war  reserve  requirement.  The  basic  role  of  a 
reorder  point  is  to  serve  as  a  trigger  alerting  the  item  manager  to  the  possible  need 
for  a  replenishment  order.  In  the  real  C&T  system,  under  SAMMS  processing,  the 
inventory  position  for  an  item  (on  hand  plus  on  order)  is  compared  three  times  a 
week  with  the  reorder  point  increased  by  any  outstanding  unit  backorders.2  In  the 
C&T  simulation,  the  comparison  is  made  every  other  day  of  simulated  time. 

With  a  simple  change  to  the  model,  the  user  can  change  the  frequency  of  the 
reorder  point  comparison.  Increasing  the  time  between  reorder  point  checks  is  one  of 
three  ways  that  users  can  make  the  simulation  run  faster.  The  other  two  are  to 
change  the  frequency  of  demand  generation  and  to  switch  off  the  logic  for  generating 


^Comparing  the  inventory  position  (on  hand  plus  on  order)  to  the  reorder  point  increased  by 
outstanding  backorders  is  equivalent  to  comparing  the  asset  position  (on  hand  plus  on  order  minus 
outstanding  backorders)  to  the  reorder  point.  The  asset-position  comparison  is  used  in  the  C&T 
simulation. 
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and  tracking  requisition  demand.  The  latter  two  options  are  discussed  in  the  next 
section  on  generating  customer  demand.  All  three  ways  speed  up  processing  time  at 
the  expense  of  certain  aspects  of  system  realism. 

The  basic  idea  of  a  reorder  point  is  that,  at  the  time  of  a  breach,  enough  stock  is 
on  hand  and  on  order  to  cover  demand  through  a  leadtime  with  a  reasonable 
expectation  of  avoiding  backorders,  but  an  order  should  be  placed  now  so  that 
replenishment  stocks  will  arrive  when  needed  a  leadtime  later.  For  a  multi-item 
PGC,  each  NSN  has  its  own  reorder  point  but  the  placement  of  replenishment  orders 
is  more  complicated,  as  will  be  described  in  a  moment. 

The  safety-level-in-months  term  in  the  reorder  point  expression  may  be  the 
value  of  fixed  safety  level  for  the  item,  read  from  the  input  data,  or  it  may  be  a  value 
obtained  from  a  file  of  VSLs  computed  with  the  C&T  VSL  model  described  in  detail 
in  Appendix  D).  Here,  it  suffices  to  say  that  the  C&T  VSL  model  operates  on  exactly 
the  same  input  data  as  the  simulation  and  prepares  a  file  of  VSL  values  for  the  set  of 
NSNs,  grouped  by  PGC,  that  a  user  wishes  to  study.  (The  VSL  model  can  compute 
VSL'values  to  either  a  safety  level  investment  target  or  a  supply  performance  target, 
for  whatever  collection  of  NSNs  it  is  given.  That  collection  may  be  the  NSNs  within 
a  single  PGC  or  those  contained  in  several  PGCs.) 

For  multi-item  PGCs,  the  C&T  Directorate  employs  a  unique  reordering 
procedure  that  goes  beyond  the  simple  comparison  of  an  NSN’s  reorder  point  with  its 
asset  position.  Before  describing  that  procedure,  however,  we  have  to  define  the 
second  quantitative  level  used  in  controlling  inventory  —  the  order  quantity  —  and 
the  associated  notion  of  a  procurement  cycle. 

Order  Quantities 

The  order  quantity  (sometimes  called  the  procurement  quantity)  for  an  NSN 
represents  the  maximum  number  of  units  of  the  item  that  will  be  ordered  on  a  single 
replenishment  order  to  a  supplier.  The  associated  procurement  cycle  is  the  number 
of  months  of  demand  (using  the  average  monthly  demand  rate  over  the  next 
12-month  period)  that  the  procurement  quantity  represents.  Procurement  cycles  are 
of  interest  because  they  give  an  indication  of  how  frequently  the  procurement  system 
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will  have  to  procure  the  item.  Procurement  quantities  (PC.EOQ)  and  associated 
procurement  cycle  periods  (PCPs)  for  C&T  POIs  are  computed  in  two  steps  as  follows: 

•  Step  1 .  Determine  the  dollar  value  of  quarterly  demand  (DVQD): 

12 

^  F.  X  Cost 

DVQD  =  ^ 3-41 

•  Step  2.  Set  procurement  quantities  and  cycles  as  follows: 


DVQD  S  Mj  =  $925 


Mj  <  DVQD  ^  Mj 


36 

PC.EOQ  =  X 

(units) 

i*l 

PCP  =  36 

(months) 

T  X  Vdvqd 

Cost 

(units) 

[Eq.  3-5] 


(T  =  365) 


PCP  =  ' '  (months) 

2 


6 

DVQD  >  Mj  =  $9,999  PC.EOQ  =  ^  F.  (units) 

PCP  =  6  (months), 

where  Fi  denotes  the  forecasted  program  requirement  in  month  (i)  from  the  '^rolling” 
60-month  requirements  array.  For  pure  QFD  items,  the  order  quantity/procurement 
cycle  rules  are  similar,  with  the  Fi  values  replaced  by  QFD/3  throughout. 

The  values  shown  for  Mi,  M2,  and  T  are  the  default  values  in  the  simulation. 
They  can  be  changed  prior  to  a  nm  through  the  use  of  the  Alternative  Assumption 
File.  (See  the  description  of  Query  11  in  Chapter  6  for  instructions  on  using  the 
Alternative  Assumption  File  and  Exhibit  A-4  in  Appendix  A  for  an  example  of  what 
the  Alternative  Assumption  File  looks  like.)  The  cutoff  values  in  Equations  3-4  and 
3-5  are  new  values  assigned  to  C&T  in  the  spring  of  1988,  replacing  values  of 
Ml  =51.36,  M2  =  1,528,  and  T  =  86  used  prior  to  that  time.  The  T  factor  is  defined  by 
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[Eq.  3-6] 

where  P  denotes  the  cost  of  placing  an  order  and  I  denotes  the  holding  cost  rate 
(holding  cost  as  a  percentage  of  unit  cost).  DLA  uses  the  T  factor  to  simplify  order 
quantity  calculations  when  all  items  at  a  given  supply  center  are  assigned  the  same 
ordering  cost  and  holding  cost  rate.3 

The  middle  value  of  the  procurement  quantity  in  Equation  3-5,  when  DVQD 
lies  between  the  Mi  and  M2  values,  is  the  traditional  Wilson  lot  size  economic  order 
quantity  (EOQ)  of  inventory  theory.  Assuming  a  value  of  18  percent  (I =0.18)  for  the 
holding  cost  rate  in  the  expression  for  T,  a  value  of  365  for  T  implies  an  order  cost,  P 
of  $2,998  per  replenishment  order  at  C&T.  The  Mi  cutoff  value  of  $925  is  consistent 
with  the  DVQD  value  at  which  the  Wilson  lot  size  corresponds  to  36  months  of 
demand.  That  is,  for  DVQD  values  smaller  than  $925  and  a  T  factor  of  365,  Wilson 
lot  sizes  are  more  than  36  months  of  demand.  The  M2  value  of  $9,999,  however,  does 
not  correspond  to  the  DVQD  at  which  Wilson  lot  sizes  become  less  than  6  months  of 
demand.  In  the  lot  size  formula,  with  a  T  value  of  365,  DVQD  has  to  be  greater  than 
$33,306  to  yield  a  procurement  cycle  of  less  than  6  months,  and  the  value  of  $9,999 
yields  a  Wilson  lot  size  procurement  cycle  of  11  months.  Nevertheless,  following 
C&T  policy  and  SAMMS  implementation,  the  M2  value  of  $9,999  is  used  as  the  cutoff 
for  establishing  procurement  cycles  of  6  months. 

With  these  definitions  of  reorder  point  and  order  quantity/procurement  cycle, 
we  can  now  describe  the  reordering  process  for  multi-item  PGCs.  Each  multi-item 
PGC  has  a  minimum  procurement  cycle  defined  in  its  MPTOll,  normally  (but  not 
necessarily)  representing  the  smallest  procurement  cycle  among  the  NSNs  in  the 
PGC.  The  reordering  rule  for  the  PGC  is  that  whenever  one  NSN  has  breached  its 
reorder  point,  it  and  any  other  NSN  that  is  within  a  minimum  procurement  cycle  of 
breaching  its  reorder  point  are  subject  to  being  ordered. 

In  the  real  world,  a  C&T  item  manager  may,  for  one  reason  or  another,  elect 
not  to  place  an  order  even  though  reorder  conditions  have  been  met.  Procurement 
funds  may  be  constrained,  for  example.  Or,  rather  than  placing  an  order,  the  item 

3For  a  discussion  of  EOQ  computations  and  other  demand-based  levels  in  SAMMS,  see  M.  K. 
Cyrus,  et  al..  Review  of  SAMMS  Requirements  Computations,  Chapter  III,  DLA  Operations 
Research  and  Economics  Analysis  Oflice,  Headquarters,  Defense  Logistics  Agency,  Cameron 
Station,  Alexandria,  Virginia,  Aug  1985. 
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manager  may  be  able  to  modify  an  existing  order  to  satisfy  the  new  requirement.  (In 
the  pastf  suppliers  have  allowed  C&T  item  managers  to  change  the  mix  of  sizes  in  an 
order  for  a  multi-item  PGC  provided  the  order  was  still  at  least  90  days  from  its 
scheduled  delivery.  The  need  for  order  changing  is  supposed  to  decrease  under  the 
new  matrix  delivery  policies.) 

In  the  C&T  simulation,  when  one  NSN  breaches  its  reorder  point,  it  and  all 
other  NSNs  in  the  PGC  that  are  within  a  minimum  procurement  cycle  of  breaching 
their  reorder  points  are  ordered.  NSNs  that  are  not  within  a  minimum  procurement 
cycle  of  breaching  are  not  ordered.  The  model  does  not  simulate  order  changing,  nor 
does  it  allow  a  funding  constraint  to  prevent  an  order  from  being  placed.  (Both  of 
those  capabilities  would  require  additional  programming  of  the  model.)  The  test  to 
see  whether  an  item  is  within  a  minimum  procurement  cycle  of  breaching  its  reorder 
point  is  done,  for  a  POI  item,  by  examining  the  forecasted  requirements  array;  for  a 
pure  QFD  item,  it  is  done  by  calculating  demands  at  a  rate  of  QFD/3  per  month. 

Acquisition  Objective 

The  final  quantitative  level  to  define  is  the  Peacetime  Acquisition  Objective 
(PTAO).  The  PTAO  determines  the  actual  size  of  an  order  when  it  is  placed.  It  is 
simply  the  sum  of  the  reorder  point  and  the  order  quantity: 

PTAO  =  ROP  4-  PC.EOQ 

The  PTAO  represents  the  upper  bound  on  the  number  of  units  of  an  item  that  should 
be  on  hand  or  on  order  at  any  given  time.  Like  its  constituent  parts  (the  reorder 
point  and  the  order  quantity),  the  PTAO  is  updated  monthly  for  VTP  items  and 
quarterly  for  non- VIP  items. 

The  C&T  rule  for  replenishment  orders  is  now  as  follows:  if  at  a  given  time,  t, 
an  NSN  has  breached  its  reorder  point  (set  earlier  at  the  beginning  of  either  the 
month  or  the  quarter),  then  for  that  NSN  and  all  other  NSNs  in  the  PGC  within  a 
minimum  procurement  cycle  of  breaching,  compare  the  asset  position  (on  hand  plus 
on  order  minus  outstanding  backorders)  as  it  exists  at  time,  t,  to  the  PTAO  as  it 
exists  at  time,  t.  If  the  asset  position  is  less  than  the  PTAO,  order  a  reorder  quantity 
equal  to  the  difference.  In  other  words,  when  placing  an  order,  order  up  to  the 
acquisition  objective  for  each  NSN  in  the  PGC  that  qualifies  for  reorder. 


Reorder  point  values  and  other  quantitative-level  values  are  not  updated  at  the 
time  of  a  reorder;  they  will  not  change  until  the  next  regularly  scheduled  update  at 
the  beginning  of  the  next  month  or  quarter.  Actual  quantities  ordered,  however,  are 
computed  on  the  basis  of  level  requirements  as  they  exist  at  the  time  of  the  order. 
The  rationale  is  that  if  an  order  is  actually  placed,  it  should  conform  to  the  most  up- 
to-date  computation  of  what  the  levels  in  the  system  should  be. 

This  completes  the  discussion  of  quantitative  levels.  We  next  describe  how 
customer  demand  is  simulated. 

MODELING  CUSTOMER  DEMAND 

In  addition  to  mimicking  the  internal  controls  (i.e.,  quantitative  levels)  the 
C&T  Directorate  uses  to  control  inventory,  the  C&T  model  must  also  simulate 
customer  behavior.  In  the  real  world,  customers  interact  with  C&T  in  many 
different  ways.  In  the  simulation,  we  focus  on  the  two  key  interactions  that  most 
strongly  affect  C&T  performance:  demand  forecasting  and  demand  itself.  In  the 
forecasting  interaction,  customers  present  the  C&T  Directorate  with  forecasts  of 
their  future  troop  strengths  and  inductions.  That  interaction  is  modeled  in  the 
requirements  forecasting  part  of  the  simulation.  In  the  demand  interaction, 
customers  actually  place  demands,  and  that  also  must  be  simulated. 

C&Ts  customers  are  retail-level  supply  outlets  at  military  installations  and 
bases.  Their  demand  on  the  wholesale  C&T  system  comes  in  the  form  of  requisitions; 
that  is,  retail  outlets  requisition  materiel  from  C&T  stock  in  varying  lot  sizes  to 
replenish  their  own  retail-level  stocks,  which  they  in  turn  issue  or  sell  to  their 
customers,  who  are  the  final  consumers  of  C&T  items.  In  honoring  requisitions, 
C&T  item  managers  draw  down  units  of  on-hand  stock  at  the  wholesale  level.  As 
stock  is  drawn  down,  C&T  item  managers  (using  SAMMS)  track  changes  in  the  unit 
asset  position  and  compare  that  position  periodically  to  the  reorder  point  quantity  to 
decide  when  and  how  much  to  order.  Simulating  customer  demand  and  how  it 
interacts  with  the  inventory  control  system,  therefore,  means  generating  and 
keeping  track  of  both  unit  demand  and  requisition  demand. 

Unit  demand  in  the  C&T  simulation  is  calculated  and  generated  using  a  two- 
step  process.  First,  a  draw  is  made  from  a  probability  distribution  for  the  total 
number  of  unit  demands  that  will  occur  in  a  given  month.  Once  that  total  has  been 
drawn,  demands  are  then  actually  generated  on  a  daily  basis  over  the  course  of  the 
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month.'^  The  same  process  is  repeated  for  the  next  month  and  each  month  thereafter 
for  the  duration  of  the  simulation.  The  entire  procedure  is  done  by  NSN, 
simultaneously  for  each  NSN  in  the  PGC,  using  NSN-specific  data  to  define  the 
distributions. 


The  distributions  from  which  the  monthly  unit  demand  totals  are  drawn  are 
obtained  as  follows:  Each  NSN  has  a  projected  monthly  demand  value  for  a  given 
month.  For  a  POI  item,  the  value  is  the  relevant  entry  in  the  60-month  require¬ 
ments  array  plus  QFD/3.  For  a  pure  QFD  item,  it  is  the  QFD  value  from  the  SSCF 
report  divided  by  three.  This  monthly  value  is  taken  as  the  mean  for  a  normal 
distribution,  with  a  standard  deviation  derived  from  the  item  mean  absoluate 
deviation  (MAD)  taken  from  the  SSCF  input  data.  MAD  is  a  measure  of  forecast 
error  defined  in  SAMMS  as  follows: 


Step  1.  Determine  the  forecast  error  in  month  m  as  follows: 

QFD(m) 


Forecast  Error  (in  month  m)  = 


+  POI  Forecast  (m) 


—  Actual  Demand  (m).  [Eq.  3-8] 


Step  2.  Define  MAD  for  month  (m+ 1)  by: 

MAO  (m-t- 1)  =  a  [Forecast  Error  (m)l  -I-  (1  -  a)  MAD  (m). 


[Eq.  3-91 


where  a  is  the  alpha  factor  from  the  SSCF  data  (defined  in  DLAM  4140.2,  Vol.  n. 
Part  3,  Appendix  F-262,  ”Alpha  Factor  Table  008,”  with  C&T  updates). 


For  a  VIP  item,  MAD  is  converted  to  a  standard  deviation  for  the  normal 
distribution  of  monthly  demand  by  multiplying  by  1.25,  following  SAMMS  practice.5 
For  a  non- VIP  item,  MAD  is  a  measure  of  the  mean  absolute  deviation  in  quarterly 
demand.  The  MAD  for  a  non- VIP  item  is  converted  to  a  monthly  standard  deviation 
by  multiplying  by  1.25  to  obtain  a  quarterly  standard  deviation  and  dividing  by  the 
square  root  of  three.  The  rationale  for  dividing  by  the  square  root  of  three  is  that  the 


^With  a  simple  change  to  the  model,  demsmds  can  be  generated  less  frequently  —  e.g.,  on  a 
weekly  rather  than  daily  basis.  This  change  slightly  speeds  up  model  run  time  because  fewer 
demand-generation  operations  must  be  performed.  However,  weekly  demand  generation  also 
requires  longer  runs  to  achieve  the  same  level  of  precision  in  results.  Daily  demand  generation  was 
chosen  as  the  default  mode  for  the  model  because,  according  to  C&T  item  managers,  requisitions  for 
many  C&T  items  arrive  every  day  and  daily  unit  demand  generation  is  necessary  to  accommodate 
that  level  of  requisition  frequency. 

^he  rationale  for  converting  a  MAD  to  a  standard  deviation  by  this  method  is  given  in 
Robert  G.  Brown,  Smoothing,  Forecasting,  and  Prediction  of  Discrete  Time  Series  (Englewood  Cliffs, 
New  Jersey;  Prentice-Hall,  1963). 
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variance  in  quarterly  demand  is  assumed  to  be  three  times  the  variance  in  monthly 
demand  and  standard  deviation  is  the  square  root  of  variance.  The  total  number  of 
demands  that  will  occur  in  a  given  month  in  the  simulation  is  the  draw  from  the 
normal  distribution  with  mean  and  standard  deviation  as  described. 

In  summary,  two  normal  distributions  are  involved  in  the  unit  demand 
generation  process  for  POI  items.  The  first  is  the  normal  distribution  used  in 
simulating  the  requirements  forecasting  process.  Its  mean  and  standard  deviation 
are  computed  from  the  monthly  forecasts  in  the  Program  Requirements  Trailer  in 
the  SSCF  input  data.  That  normal  distribution  is  drawn  from  to  make  the  rolling 
60-month  requirements  array.  The  second  normal  distribution  applies  to  a  single 
month.  Its  mean  is  the  value  from  the  60-month  requirements  array  for  the  month 
in  question,  and  its  standard  deviation  is  obtained  from  the  item  MAD. 

As  noted  earlier,  unit  demands  in  the  simulation  are  actually  generated  daily. 
The  total  demands  drawn  for  the  month  are  divided  by  30  to  determine  daily 
demands.  (Every  month  in  the  simulation  is  30  days  long.)  Thus,  within  a  month, 
the  unit  demands  are  the  same  from  one  day  to  the  next.  Users  have  the  option  of 
generating  unit  demand  less  frequently  than  daily,  if  desired.  They  may  also  draw 
daily  demands  from  a  Poisson  distribution  with  mean  equal  to  the  monthly  demand 
divided  by  30.  (This  option  requires  a  minor  programming  change  in  the  model  and 
introduces  an  extra  source  of  variance  that  may  not  be  desirable.) 

The  preceding  method  yields  unit  demand  patterns  that  conform  to  C&T 
demand  experience  as  reflected  in  C&T  data.  For  some  applications,  however,  users 
may  wish  to  experiment  with  different  demand  patterns.  If  the  forecasted  demand 
for  a  PGC  is  believed  to  be  too  high  or  too  low,  users  may  want  to  take  that  into 
account.  Users  can  reduce  or  increase  generated  demands  through  the  use  of  a 
demand  control  knob  at  the  beginning  of  a  run.  The  demand  control  knob  changes 
the  value  of  the  means  in  the  normal  distributions  from  which  monthly  demand 
values  are  drawn.  For  example,  a  value  of  0.95  will  convert  every  forecasted 
monthly  mean  to  95  percent  of  its  value  prior  to  demand  generation,  while  a  value  of 
1.05  will  increase  every  mean  to  105  percent  of  its  value. 

The  next  step  is  to  describe  how  requisition  demand  is  generated.  Requisitions 
are  modeled  as  accumulated  unit  demand.  To  decide  when  enough  unit  demands 
have  accumulated  to  generate  a  requisition,  the  simulation  performs  a  computation 
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involving  the  average  requisition  size  of  the  NSN  and  a  distribution  for  the  ratio  of 
requisition  size  to  average  requisition  size. 

Average  requisition  size  by  NSN  is  computed  from  the  input  data  in  the 
Demand/Retrims  Trailer  of  the  SSCF  report  and  is  stored  as  a  data  element  in  the 
SSCF  input  file  for  the  model  [see  the  description  of  the  average  requisition  size 
(ARS)  data  element  in  Chapter  2]. 

The  distribution  for  the  ratio  of  requisition  size  to  average  requisition  size  is 
one  that  applies  to  all  requisitions  arriving  at  DPSC.  It  was  developed  for  DLA’s 
Uniform  SAMMS  Inventory  Management  Simulation  (USIMS)  based  on  1984  data.6 
The  distribution  reflects  DPSC  experience  with  subsistence  and  medical  items,  as 
well  as  with  C&T  items.  The  distribution  applies  to  DPSC  items  whose  average 
requisition  size  is  greater  than  five.  The  distribution  is  shown  in  Appendix  A  in 
Exhibit  A-5. 

To  generate  a  requisition,  a  draw  is  made  from  the  USIMS  distribution  to 
obtain  a  ratio,  which  is  then  multiplied  by  the  average  requisition  size  for  the  NSN. 
This  gives  a  requisition  size  number  for  the  next  requisition.  As  soon  as  enough  unit 
demands  have  accumulated  to  equal  (or  exceed)  the  requisition  size  number,  the 
requisition  demand  occurs,  the  requisitioned  number  of  units  of  stock  are  drawn 
down,  a  new  draw  is  made,  and  the  next  requisition  size  number  is  generated. 
Remaining  unit  demands,  if  any,  begin  to  accumulate  towards  the  next  requisition. 
If  insufficient  stock  is  on  hand  to  fill  the  requisition,  whatever  units  are  on  hand  are 
drawn  down,  unit  backorders  are  generated  for  the  difference,  and  the  requisition  is 
counted  as  a  ^nonfill”  in  determining  requisition  supply  availability. 

For  the  half  dozen  PGCs  examined  during  development  (chosen  by  the  DLA 
C&T  Directorate  as  a  small,  representative  cross- section  of  its  items),  the 
simulation’s  demand-generating  process  results  in  requisitions  occurring  roughly 
every  1  to  4  days. 

To  sharpen  the  process  for  generating  requisitions,  DLA  should  obtain  the 
USIMS  requisition- size  distribution  for  C&T  items  alone.  The  distribution  now  used 
is  clouded  by  the  inclusion  of  medical  and  subsistence  items.  An  alternative 

^AppendixW  of  the  Uniform  SAMMS  Inventory  Management  Simulation  (USIMS)  User’s 
Guide,  January  1986,  available  from  the  OLA  Operations  Research  and  Economic  Analysis  Office, 
documents  the  requisition  size  distributions  developed  for  USIMS. 
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approach  is  to  construct  NSN-specific  distributions.  From  the  four  quarters  of 
historical  demand  data  in  Trailer  E  of  an  SSCF  report  where  both  quantity 
demanded  (unit  demand)  and  frequency  of  demand  (number  of  requisitions)  are 
recorded,  DLA  could  construct  NSN-specific  distributions  of  requisition  size  for  each 
NSN  in  a  PGC  rather  than  using  the  DPSC-wide  distribution.  We  have  not  included 
this  feature  in  the  current  version  of  the  simulation  but  we  could  add  it  in  the  future. 

A  special  feature  of  the  C&T  simulation  is  its  ability  to  separately  identify  and 
track  demand  from  Recruit  Training  Centers  (RTCs).  It  does  so  in  the  requisition 
generation  process. 

Thus  far,  we  have  seen  that  both  unit  demands  and  requisition  demands  are 
generated  in  the  simulation  from  what  amounts  to  a  single  source.  The  simulation 
does  not  have  multiple  demand  generators  representing  the  multiple  retail  supply 
activities  that  place  demands  on  the  C&T  system  in  the  real  world.  Nevertheless, 
the  simulation  identifies  RTC  demand.  It  does  so  by  recognizing  that  RTC  demand 
tends  to  come  in  the  form  of  large  requisitions;  that  is,  replenishment  requisitions 
from  RTCs  are  usually  for  sizable  quantities.  The  key  to  identifsring  RTC  demand, 
therefore,  involves  deciding  what  constitutes  a  large  requisition. 

As  described  in  Chapter  2,  the  SSCF  input  data  file  contains  a  percent  RTC 
demand  figure  computed  from  the  Program  Requirements  Trailer  (Trailer  U)  data 
for  each  NSN.  That  percent  represents  the  portion  of  total  projected  unit  demand 
associated  with  Tnitial  Issue  -  Recruit”  program  identification  codes.  The  percent 
RTC  demand  figure,  in  conjunction  with  the  underlying  probability  density  function 
(pdf)  for  requisition  size  for  the  NSN,  can  be  used  to  find  the  right  requisition-size 
cutoff  value  for  RTC  requisitions  using  the  following  argument: 

Find  the  cutoff  value,  c,  such  that: 

f.  (i)  =  RTCP  21  f  (i).'  [Eq.  3-10] 

i2c 

where  fi  denotes  the  absolute  frequency  of  requisitions  of  size  i  and  RTCP  denotes  the 
percentage  of  RTC  demand.  The  product  of  frequency  and  requisition  sizes,  summed 
over  all  requisition  sizes,  yields  total  unit  demand,  and  the  sense  of  Equation  3-10  is 
that  requisitions  whose  size  is  greater  than  or  equal  to  c  account  for  the  RTC 
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percentage  of  total  unit  demand.  Converting  the  absolute  frequencies,  fi,  to  relative 
frequencies,  ri,  by  dividing  by  Zfi  yields  the  equivalent  problem: 

Find  c  such  that 

^  r,  (i)  =  RTCP  XARS,  [Eq.  3-11] 

where  ARS  denotes  the  average  requisition  size.  The  relative  frequencies,  n,  are  the 
probabilities  that  make  up  the  pdf  for  requisition  size  underlying  the  USEMS 
distribution. 

Figure  3-1  illustrates  how  the  cutoff  value  is  determined  for  an  item  with  an 
average  requisition  size  of  25  units  and  a  percent  RTC  demand  value  of  30  percent. 
The  lower  curve  in  the  figure  is  a  graph  of 

ir(i) 

i  =  l _  [Eq.  3-12] 

ARS  ’ 

(expressed  as  a  percentage)  plotted  over  requisition  size,  c.  The  upper  curve  is  a  plot 
of  the  cumulative  distribution  function  (cdf)  for  requisition  size.  The  percentage  of 
demand  associated  with  requisitions  of  size,  s,  or  less  is  obtained  by  locating  s  on  the 
horizontal  axis  and  reading  up  and  across  to  the  left.  In  the  figure,  70  percent  of 
demand  corresponds  to  requisitions  of  113  units  or  less,  so  30  percent  of  demand 
comes  from  requisitions  of  more  than  113  units,  and  113  units  is  the  desired  cutoff 
value  for  determining  RTC  requisitions  for  this  item. 

The  generation  and  tracking  of  requisition  demand,  including  the  separate 
identification  of  RTC  requisitions,  is  an  important  feature  of  the  C&T  simulation. 
However,  it  is  possible  to  run  a  unit-demand-only  version  of  the  simulation  using  a 
switch  in  the  Alternative  Assumption  File  that  shuts  off  the  requisition-generating 
machinery.  The  model  runs  about  30  percent  faster  if  requisitions  are  not  generated. 
Running  the  model  in  this  mode  is  appropriate  when  overall  unit  demand  and  supply 
performance  are  the  only  measures  of  interest. 

SIMULATING  SUPPLIER  RESPONSIVENESS 

Supplier  responsiveness  —  the  ability  of  suppliers  to  deliver  replenishment 
orders  on  time  —  is  the  final  C&T  operation  to  be  simulated.  Supplier 


3-17 


Percent 

I 


o  Requisition  distribution  Requisition  size  (units) 

X  Percent  of  unit  demand 


FIG.  3-1.  RTC  REQUISITION  SIZE  CUTOFF  LOGIC 

responsiveness,  or  the  lack  of  it,  affects  C&Ts  inventory  performance  at  least  as 
much  as  changing  customer  demands  and  internal  inventory  controls.  C&T 
suppliers,  many  of  whom  are  small  businesses,  are  subject  to  market  forces  that  can 
strongly  influence  their  ability  to  produce  and  deliver  on  time.  C&T  is  also  just  one 
among  many  customers  competing  for  clothing  and  apparel  items  in  the  economy. 

The  simulation  of  supplier  responsiveness  is  based  on  administrative  leadtimes 
in  Supply  Control  Files,  delivery  schedule  plans  in  Management  Policy  Tables,  and 
historical  information  on  contractor  delinquencies.  The  simulation  combines  all  this 
information  to  determine  when  replenishment  orders  are  delivered.  In  the 
simulation,  emphasis  is  placed  on  inventory  effects  rather  than  contract 
management;  no  attempt  is  made  to  simulate  the  contractual  activities  involved  in 
the  placing  of  orders.  Following  the  reordering  processes  described  earlier, 
replenishment  orders  are  simply  placed  and  stock  arrives  late  or  early.  Leadtime 
variability  (i.e.,  whether  deliveries  are  late  or  early)  is  based  on  draws  from  a 
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probability  distribution  that  describes  how  suppliers  perform  in  the  real  world.  The 
user  can  change  degree  of  leadtime  variability  through  a  control  knob. 


The  first  step  in  determining  when  and  how  a  replenishment  order  will  be 
delivered  is  to  determine  the  matrix  delivery  schedule  for  each  item.  The 
methodology  for  constructing  those  schedules  is  given  in  DLAM  4140.2,  Chapter  26, 
Delivery  Schedules  (Working  Copy).  In  some  schedules,  the  entire  order  of  an  NSN  is 
delivered  at  one  time  in  a  "clump.”  In  other  schedules,  the  order  is  delivered 
incrementally  over  several  months.  The  type  of  delivery  schedule  depends  upon  the 
information  in  the  MPTOll:  the  method  of  delivery,  the  XYZ  cutoffs  that  determine 
whether  a  NSN  is  an  X,  Y,  or  Z  item,  and  the  delivery  percentages  by  month  for  the 
order. 

The  individual  delivery  schedules  for  the  X,  Y,  and  Z  items  are  calculated  at 
the  beginning  of  the  simulation  and  do  not  change.  Each  item  schedule  specifies 
what  percent  of  the  item’s  total  order  is  delivered  in  each  month  of  the  delivery 
period  for  the  PGC.  The  schedules  depend  on  the  matrix  delivery  method  and  are 
constructed  so  that  the  sum  of  all  deliveries  in  any  month  equals  the  delivery 
percentage  for  that  month.  Each  of  the  four  matrix  delivery  methods  is  different. 

In  Method  1,  the  NSNs  with  the  largest  orders  are  delivered  first.  Deliveries 
are  spread  across  the  delivery  period  until  all  NSNs  are  delivered.  The 
distinguishing  feature  of  Method  1  is  that  the  entire  order  for  each  NSN  is  delivered 
at  one  time  in  a  clump. 

In  Method  2,  all  Z  items  are  delivered  in  clumps  in  the  last  month  of  the 
delivery  period;  Y  items  are  delivered  incrementally  in  the  last  half  of  the  period; 
and  X  items  are  delivered  incrementally  across  the  entire  period. 

In  Method  3,  Z  items  are  delivered  in  clumps  across  the  last  two-thirds  of  the 
delivery  period,  while  X  and  Y  items  are  delivered  incrementally  across  all  delivery 
months. 

Method  4  is  identical  with  Method  3  except  that  Z  items  are  delivered  only  in 
the  last  month  of  the  delivery  period. 

The  next  step  is  to  determine  the  delay  for  the  delivery.  To  do  so,  the 
simulation  employs  an  empirical  distribution.  The  histogram  for  the  delivery  delay 
distribution  is  shown  in  Figure  3-2.  The  distribution  was  constructed  from  data  in 
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C&T  Contract  Line  Item  Number  (CLIN)  Delinquency  Reports  for  the  months  of 
April,  June,  August,  September,  and  October  1987.  The  CLIN  Delinquency  Reports 
record  both  the  number  of  outstanding  contract  line  items  for  which  suppliers  have 
missed  delivery  dates  and  the  percentage  that  number  is  of  the  total  number  of 
active  CLINs.  Table  3-1  contains  the  relevant  CLIN  data  underlying  the  histogram 
in  Figure  3-2. 


Delay  (days) 

FIG.  3-2.  DELIVERY  DELAY  HISTOGRAM 


TABLE  3-1 

1987  C&T  CLIN  DEUNQUENCY  REPORT  DATA 


1987 

Total 

31  -  90  days  late 

91  -  180  days  late 

>  180  days  late 

month 

CUNs 

Number 

Percent 

Number 

Percent 

Number 

Percent 

April 

26,757 

1,927 

7.20 

1,442 

5.39 

3,133 

n 

June 

25,223 

1,900 

7.53 

1,215 

4.82 

3,091 

Warn 

August 

25,702 

2,087 

8.12 

1,710 

6.65 

3,157 

September 

25,297 

2068 

8.17 

1,845 

7.29 

3,388 

13.39 

October 

22,995 

1,650 

7.18 

1,819 

7.91 

2,876 

12.51 

The  assumption  is  that  items  ordered  in  the  simulation  correspond  to  active 
CLINs  (i.e.,  line  items  on  order).  The  three  right-hand  bars  in  the  histogram 
correspond  to  the  average  percentage  values  of  7.64  percent,  6.41  percent,  and 
12.43  percent  in  Table  3-1.  The  upper  bound  of  360  days  late  was  based  on 
discussions  with  C&T  personnel,  who  indicated  that  very  late  contracts  (contracts 
later  than  12  months)  would  generally  be  moved  into  a  different  status  and  new 
contracts  would  be  let.  With  this  configuration  of  the  delivery  delay  distribution,  the 
simulation  assumes  that,  even  if  a  second  contract  is  required,  delivery  is  nevermore 
than  360  days  late.  Similarly,  the  leftmost  bar  in  the  histogram  is  based  on 
subjective  C&T  estimates  that  no  delivery  would  ever  be  more  than  20  days  early 
and  that  no  more  than  10  percent  of  contracts  would  be  delivered  early  in  any  case. 
The  tall  bar  in  the  histogram  represents  what  is  left  —  the  contracts  that  are 
delivered  essentially  on  time,  i.e.,  within  30  days  of  scheduled  delivery. 

Each  time  a  replenishment  order  is  placed  in  the  simulation,  the  total  leadtime 
is  determined  and  a  draw  is  made  from  the  delay  distribution  to  determine  how 
many  days  late  or  early  the  delivery  will  be  made  in  relation  to  the  total  leadtime. 

The  simulation  determines  when  deliveries  take  place  by  summing  three 
factors:  the  administrative  leadtime  in  days,  the  time  to  first  delivery  in  days,  and 
the  delay  time  in  days  drawn  from  the  delivery  delay  distribution.  The  sum  is  the 
number  of  days  that  pass  from  the  time  an  order  is  placed  to  the  time  of  the  first 
delivery  at  the  end  of  the  first  delivery  month  in  the  schedule.  The  second  delivery 
occurs  30  days  later  at  the  end  of  the  second  delivery  month  and  so  forth  until  the 
delivery  schedule  is  completed. 

Because  of  the  way  matrix  delivery  schedules  are  designed  for  some  items,  the 
actual  delivery  leadtime  will  not  equal  the  reorder  point  leadtime  even  if  no  delivery 
delay  occurs.  With  incremental  deliveries,  for  example,  the  reorder  point  leadtime 
usually  falls  in  the  middle  of  the  schedule  of  deliveries  so  some  items  arrive  before 
the  leadtime  and  some  after.  For  Method  1  items,  which  are  not  supposed  to  be 
delivered  incrementally,  delivery  leadtimes  still  may  not  match  reorder  point 
leadtimes  because  reorder  point  leadtimes  are  not  always  based  on  the  actual  month 
of  delivery.  (This  potential  flaw  in  Method  1  implementation  is  discussed  further  in 
Chapter  7.) 
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In  using  the  data  in  Table  3-1  and  the  associated  distribution,  we  are  assuming 
that  the  basic  characteristics  of  C&T  supplier  responsiveness  are  described  by  those 
data  and  that  those  characteristics  do  not  change  over  time.  The  stability  from  one 
month  to  the  next  in  the  percentage  values  within  each  period  in  Table  3-1  supports 
those  assiunptions.  However,  the  new  delivery  schedules  being  introduced  by  the 
C&T  Directorate  are  supposed  to  improve  supplier  responsiveness.  If  they  do,  the 
delivery  delay  distribution  will  need  to  be  updated.  In  the  meantime,  the  simulation 
allows  the  user,  through  the  use  of  a  control  knob,  to  adjust  the  variability  reflected 
in  the  delivery  delay  distribution.  The  PLT  control  knob,  which  can  be  set  to  any 
nonzero  value,  changes  the  scale  over  which  the  delay  distribution  is  defined  (see 
Figure  3-3).  With  a  setting  of  1.0,  the  distribution  is  unchanged  and  results  in 
deliveries  that  are  55  days  late  on  average.  With  a  setting  of  0.5,  deliveries  will  be 
27.5  days  late  on  average,  while  a  setting  of  2.0  will  make  them  110  days  late  on 
average. 


Percent 

of 

active 

CLINs 


Delay  (days) 


360 

J_ 

180 


720 


PLT  knob  -  1.0 

PLT  knob  -  0.5 

PLT  knob  ■  2.0 


FIG.  3-3.  EFFECT  OF  THE  PLT  CONTROL  KNOB  SETTINGS 


The  PLT  control  knob  allows  a  user  to  tailor  leadtime  variabilities.  If,  for  a 
given  PGC,  the  user  has  an  idea  about  how  many  days  late  deliveries  are  likely  to  be, 


3-22 


the  PLT  control  knob  can  be  set  so  that  the  average  delay  matches  the  estimated 
lateness.  This  converts  the  user’s  estimate  of  a  likely  event  into  a  mean  value  about 
which  the  simulation  will  operate.  This  feature  of  the  simulation  can  be  used  to 
examine  the  effects  if  the  new  delivery  schedules  reduce  leadtime  variabilities. 

A  final  point  on  the  simulation  of  supplier  responsiveness  involves  the 
deliberate  "coupling”  of  reorder  point  leadtimes  with  delivery  leadtimes.  In  the  C&T 
simulation,  delivery  leadtimes,  which  identify  the  points  in  simulated  time  about 
which  deliveries  will  take  place,  correspond  to  the  leadtimes  used  to  set  reorder 
points.  This  was  done  deliberately  in  order  to  approximate  the  effect  of  the  "needs 
test”  procedure  being  implemented  as  part  of  the  new  C&T  delivery  policy. 

The  new  DLA  C&T  Directorate  policy  for  delivery  schedules  for  multi-item 
PGCs  is  that  for  a  given  replenishment  order,  items  shall  be  classified  as  X,  Y,  or  Z 
according  to  how  the  item’s  order  amount  compares  with  the  total  amount  of  the 
order.  In  a  multi-item  PGC,  order  amounts  can  be  different  from  full  order 
quantities  because  items  can  be  reordered  before  they  reach  their  reorder  points. 
Thus,  items  that  are  classified  X,  Y,  or  Z  when  the  reorder  point  is  set  can  have  a 
different  classification  when  a  delivery  schedule  is  made.  Delivery  leadtimes  were 
deliberately  decoupled  from  reorder  point  leadtimes  to  accommodate  delivery 
schedules  that  suppliers  will,  theoretically,  be  better  able  to  provide.  However,  the 
new  delivery  policy  also  calls  for  a  needs  test.  Given  projected  demand,  if  a  planned 
delivery  schedule  generates  a  need,  i.e.,  requires  the  use  of  safety-level  stocks,  the 
delivery  schedule  must  be  modified  to  avoid  that  problem. 

The  effect  of  the  needs  test  is  to  move  scheduled  deliveries  back  towards  what 
they  would  ^e  if  reorder  point  leadtimes  were  used  to  make  the  schedule  in  the  first 
place.  To  approximate  the  effect  of  the  needs  test,  therefore,  the  simulation  couples 
delivery  and  reorder  point  leadtimes.  (So  that  "X”  items  for  reorder  point  purposes 
are  always  "X”  items  in  the  delivery  schedule,  for  example).  By  doing  so,  the 
simulation  is  able  to  approximate  —  usually  within  a  month  —  what  delivery 
schedules  would  look  like  after  application  of  the  needs  test. 

This  chapter  has  described  each  of  the  four  aspects  of  C&T  inventory 
management  —  requirements  forecasting,  inventory  control,  customer  demand,  and 
supplier  responsiveness  —  and  how  each  is  simulated.  As  an  analysis  tool,  the  C&T 
simulation  is  best  suited  to  questions  that  relate  to  these  four  activities. 
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The  [ORDERS/YR]  entry  is  the  average  number  of  replenishment  orders  for 
the  PGC  placed  with  suppliers  per  year,  computed  over  the  number  of  simulated 
years  in  the  run.  This  output  is  a  good  indicator  of  whether  the  simulation  is 
matching  ical-world  behavior  for  the  PGC. 

Time- weighted  backorders  [TIME  WGHT  BO]  refers  to  the  average  number  of 
outstanding  backorders  present  in  the  system  over  time.  [At  any  given  time,  t,  an 
inventory  system  will  have  some  number  of  outstanding  backorders,  b(t),  to 
customers  (perhaps  zero).  The  average  value  of  b(t)  over  time  is  time-weighted 
backorders.]  For  DoD  supply  systems,  time-weighted  backorders  [sometimes  called 
expected  backorders  (EBOs)  or  average  backorders  on  hand]  represent  the  single 
most  important  measure  for  gauging  how  supply  customers  are  being  supported. 

The  [AVAILABILITY]  entry  reflects  cumulative  supply  availability  rates  over 
the  course  of  the  run.  All  backorder,  availability,  and  [DEMANDS/YR]  statistics  are 
reported  for  requisition  demand  and  unit  demand,  considering  both  overall  demand 
[TOT]  and  Recruit  Training  Center  [RTC]  demand. 

The  average  values  [STOCK]  and  [ON  ORDER]  are  time-weighted  averages  of 
stock  on  hand  and  stock  on  order.  The  average  [SAFETY  LEVEL]  entry  reflects  the 
quantity  and  value  of  safety  level  carried  in  the  system  for  the  PGC.  It  is  computed 
by  multiplying  the  safety  level  in  months  for  the  NSN  (flxed  or  variable)  by  the 
underlying  average  monthly  forecast  for  the  NSN  and  then  summing  over  all  NSNs 
in  the  PGC. 

The  calibration/validation  information  at  the  bottom  of  the  Summary  PGC 
Report  presents  additional  information  about  a  run.  The  total  length  of  time 
simulated,  including  the  warm-up  period,  is  listed  next  to  [TIME.V(YR)].  The  length 
of  time  over  which  statistics  were  acciunulated  is  [SIM(YRS)],  and  the  length  of  the 
warm-up  period  in  years  appears  next  to  [WARMUP].  The  parenthetical 
information  following  the  [WARMUP]  entry  states  how  often  reorder  points  are 
checked  in  the  simulation  (e.g.,  [REVIEW  2]  means  reorder  points  are  checked  every 
other  day)  and  how  often  demands  are  generated  (e.g.,  [DEMAND  1]  means  demands 
are  generated  daily). 

The  [PGC.BO]  entry  is  a  sampling  estimate  of  the  average  number  of 
outstanding  requisition  backorders.  It  is  obtained  by  averaging  values  of 
outstanding  requisition  backorders  taken  in  "snapshots”  over  the  course  of  the  run. 
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The  longer  the  run,  the  closer  the  value  of  [PGC.BO]  will  match  the  accumulated 
value  of  [TIME  WGHT  BO]  for  requisition  backorders. 

The  [%  CI/MEAN]  entry  is  related  to  a  95  percent  confidence  interval  estimate 
of  time-weighted  requisition  backorders.  The  confidence  interval  estimate  is 
centered  on  the  [PGC.BO]  point  estimate.  The  [%  CI/MEAN]  entry  is  the  ratio  of  the 
radius  of  the  interval  estimate  to  the  point  estimate,  expressed  as  a  percent.  [% 
CI/MEAN]  provides  a  measure  of  the  relative  precision  of  the  result  for  outstanding 
requisition  backorders.  A  large  percentage  value  for  [%  CI/MEAN]  indicates 
considerable  relative  variability  about  the  average  number  of  outstanding 
backorders.  If  the  number  of  average  outstanding  backorders  is  small,  it  is  possible 
for  [%  CI/MEAN]  to  be  large  even  though  the  interval  estimate  for  backorders  may 
be  narrow  in  absolute  terms.  For  example,  an  interval  estimate  of  10  ±  5 
outstanding  backorders  on  average  may  be  an  acceptably  precise  result,  even  though 
the  [%  CI/MEAN]  ratio  is  5/10  or  50  percent. 

The  [AVE  NET  STOCK]  entry  is  a  sampling  estimate  of  the  average  amount  of 
on-hand  stock  minus  backorders  for  the  PGC.  It  is  the  mean  for  the  PGC  Net  Stock 
histogram,  which  is  discussed  further  later. 

The  [%  OR/OH + OR]  entry  is  the  ratio  of  average  on-order  stock  (in  units)  to 
the  siun  of  on-hand  and  on-order  stock  (in  units).  It  is  often  a  more  useful  validation 
measure  than  backorders  because  backorders  may  be  relatively  rare. 

The  [%  FORE/DEMD]  entry  is  the  ratio  of  average  annual  forecasted  unit 
demand  (as  it  occurred  in  the  simulation)  to  the  annual  average  of  actual  demand  (as 
it  occurred  in  the  simulation).  In  Exhibit  4-1,  for  example,  94.13  percent  is  the  ratio 
of  the  average  annual  forecast  [YR  FORCST]  of  252,009  units  to  the 
[DEMANDS/YR]  average  of  267,713  units  actually  demanded.  Because  of  left- 
handed  tnmcation  effects  in  normal  distributions  (especially  when  item  MADs  are 
very  large  relative  to  the  mean  forecast),  the  [%  FORE/DEMD]  ratio  is  often  less 
than  100  percent  even  for  long  runs. 

THE  AGGREGATE  PGC  REPORT 

Although  the  C&T  simulation  runs  one  PGC  at  a  time,  users  may  want  to  see 
the  results  of  several  runs  on  the  same  PGC,  or  —  even  more  likely  —  the  results  of 
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one  run  on  several  different  PGCs.  The  Aggregate  PGC  Report  is  designed  to 
support  such  multiple-run/multiple-PGC  analyses. 

Exhibit  4-2  shows  an  Aggregate  PGC  Report  containing  the  results  of  the  same 
run  done  on  three  different  PGCs.  The  (TOTAL]  line  shows  that  for  the  system  of 
three  PGCs,  the  average  number  of  on-hand  backorders  for  the  system  is  2,886  unit 
backorders  and  155  requisition  backorders.  The  [TOTAL]  figures  for  system 
requisition  supply  availability  show  that  the  demand-weighted  average  of  the  three 
PGC  availabilities  is  98  percent  —  both  overall  and  considering  requisition  supply 
availability  to  RTCs  alone.  The  [UNIT  AMD/100]  column  shows  average  monthly 
demand  in  100s  of  units,  while  the  other  demand  columns  show  average  number  of 
requisition  demands  per  month  —  both  overall  and  from  RTCs. 
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EXHIBIT 4-2.  AGGREGATE  PGC  REPORT 

When  the  Aggregate  PGC  Report  is  used  to  summarize  the  results  of  several 
different  runs  on  the  same  PGC,  the  [TOTAL]  line  does  not  appear  and  the  [PGC/ID] 
column  contains  the  run  ID  number  rather  than  a  listing  of  PGC  numbers.  The  user 
controls  the  configuration  of  the  Aggregate  PGC  Report  through  Query  6  (see 
Chapter  6). 
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THE  DETAIL  TRACE  OUTPUT  REPORT 

The  Detail  Trace  Output  Report  contains  a  detailed  audit  trail  of  all  the 
simulation  activities,  as  well  as  input  data  and  output  reports.  Specifically,  the 
report  contains  four  sections:  Input  Data,  Simulation  Data  Description,  Simulation 
Over  Time,  and  End  of  Run:  PGC  Results. 

Trace  output  changes  slightly  based  on  user  responses  to  model  queries.  A 
short-duration  simulation  produces  extensive  and  detailed  trace  information.  For  a 
long-duration  simulation,  the  volume  of  information  in  the  trace  is  automatically 
reduced.  Appendix  B  contains  an  example  of  the  Detail  Trace  Output  Report  for  a 
long-duration  simulation,  the  "demonstration”  PGC  (3  NSNs). 

The  Input  Data 

The  Input  Data  section  of  the  Detail  Trace  Output  Report  reproduces  the 
information  in  the  MPTOll  and  SSCF  input  files. 

The  Simulation  Data  Description 

The  Simulation  Data  Description  section  in  the  Detail  Trace  Output  Report 
contains  the  data  used  by  the  simulation.  Some  of  those  data  are  taken  directly  from 
input  files,  while  other  data  must  be  combined  and  converted  to  a  ‘‘jrm  required  by 
the  model.  The  following  paragraphs  describe  the  five  data  tables  in  the  section. 

The  DELIVERY  MATRIX  FOR  X,  Y,  AND  Z  ITEMS  table  displays  the 
percentages  that  show  how  the  total  order  is  delivered  over  the  delivery  period. 
Percentages  are  by  item  classification  (X,  Y,  Z)  and  are  calculated  by  the  model 
based  on  the  method  of  delivery,  the  delivery  percentages  at  the  PGC  level,  and  the 
XYZ  item  percent  cutoff. 

The  SUMMARY  OF  MONTHLY  TOTAL  FORECAST  AND  C&T  36  MONTH 
POI  FORECASTS  table  displays  the  total  average  monthly  forecast  [TOTAL  AMF], 
the  POI  average  forecast  from  the  SSCF  data  [POI  AMF],  and  the  POI  standard 
deviation  [POI  STD]  obtained  from  the  NSN  input  forecasts  in  the  SSCF  input  file. 

The  CURRENT  CTREQ.MAT  table  displays  the  model-generated  POI 
forecasts  by  NSN  for  the  first  90  months.  The  table  is  generated  from  a  normal 
distribution  with  the  mean  and  standard  deviation  displayed  in  the  previous  table. 
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The  CURRENT  CTREQ.MAT  table  is  displayed  only  for  short-duration  runs  and  is 
not  shown  in  Appendix  B. 

The  MODEL  OPTION  ASSUMPTIONS  table  displays  the  user-entered 
responses  to  the  interactive  query  session. 

The  table,  KEY  VARIABLES  USED  IN  RUN  table  displays  input  data  and 
model-generated  data.  The  model-generated  data  are  the  RTC  cutoff  [RTC  CUT], 
the  standard  deviation  of  demand  divided  by  the  average  monthly  total  forecast 
expressed  as  a  percent  [%SD/AMF],  and  the  item  type  [XYZ]  where  X  is  1,  Y  is  2,  and 
Zis3. 

The  Simulation  Over  Time 

The  Simulation  over  Time  section  of  the  Detail  Trace  Output  Report  displays 
inventory  status  over  simulated  time.  Information  is  recorded  every  year  in  a  short- 
duration  run  and  at  the  halfway  and  end  points  of  a  long-duration  run. 

The  BEGINNING  OF  MONTH  table  displays  the  starting  inventory  levels  for 
the  month  by  NSN:  the  monthly  demand  and  forecast,  the  procurement  cycles, 
reorder  point,  stock  on  hand  and  on  order,  and  the  unit  backorders  (UBO)  and 
requisitions  backorders  (RBO). 

The  END  OF  MONTH  DATA  table  displays  cumulative  statistics  up  to  the 
current  time  by  NSN:  the  average  requisition  size  [APJS.SM]  and  the  average  time 
interval  in  days  between  requisitions  [INTRVL];  the  average  monthly  forecast 
[AMF]  and  the  ratio  of  forecast  to  actual  demand  [FOR/DD];  the  on-hand  and  on- 
order  inventory;  the  on-order  inventory  as  a  percentage  of  the  on-hand  plus  on-order 
inventory  [%0/0];  and  the  on-order  inventory  divided  by  AMF  [OR/F],  the  on-hand 
inventory  divided  by  AMF  [OH/F],  and  the  war  reserve  inventory  divided  by  AMF 
[WAR].  The  latter  five  variables  are  generated  to.  facilitate  comparison  of  model 
results  with  Flash  Report  results  (discussed  in  Chapter  5). 

The  next  table  displays  average  backorder  delay  in  days  [AVBOD],  the 
demands  per  year  [DEM/YR],  time- weighted  backorders  [EBOs],  and  the  demand- 
weighted  supply  availability  [FILL  RATES]  by  NSN.  The  left  side  of  that  table 
shows  that  data  at  a  requisition  level  and  the  right  side,  at  a  unit  level.  The  table 
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also  distingwshes  between  all  customers  [TOT]  and  Recruit  Training  Center  [RTC] 
customers. 

For  long-dtiration  runs,  a  line  is  printed  [QUICK]  every  2  years  displaying  a 
quick  approximation  of  the  confidence  interval  estimate  for  requisition  backorders 
so  the  user  can  see  how  average  backorders  are  varying  with  time.  The  following 
PGC  statistics  are  printed:  the  year  [YR],  the  mean  requisition  backorders  up  to  this 
time  [MEAN],  the  current  net  stock  [NETSTOCK],  the  95  percent  confidence 
interval  radius  [Cl],  and  the  Cl  radius  divided  by  the  MEAN  expressed  as  a  percent 
[%CI/AVE].  The  QUICK  line  can  be  printed  by  NSN,  if  desired.  As  currently 
configured,  it  contains  PGC-level  statistics.  The  term  QUICK  NSN  1  indicates  PGC- 
level  statistics  if  no  other  NSNs  appear. 

For  short-duration  runs,  the  simulation  displays  three  additional  tables,  all 
with  NSN-specific  information.  The  first  table.  Breach  Time,  displays  inventory 
conditions  at  the  time  of  the  breach:  size  of  order  [ORDER];  on-hand  stock;  on-order 
stock;  reorder  points;  and  backorders  [BO]  at  a  unit  level  [U],  at  the  requisition  level 
[REQ]  and  for  recruits  [RC].  The  second  table  is  printed  each  month  with  the 
monthly  demand  [DEMAND-MONTH]  and  the  monthly  forecast  [FORCST-MTH]. 
The  third  table.  Deliver  Order,  displays  when  the  order  is  received,  the  delivery 
month  [SCH  MTH]  in  the  matrix  schedule,  and  the  size  of  the  incremental  delivery 
[QUANTITY]. 

End  of  Run:  PGC  Results 

The  End  of  Run:  PGC  Results  table  of  the  Detail  Trace  Output  Report  displays 
several  tables  summarizing  the  results  of  the  simulation  at  the  PGC  level.  The  first 
table,  STATS  FOR  RUN,  displays  information  used  by  the  model  to  calculate  a 
confidence  interval.  That  information  includes  the  following:  the  time  interval  in 
days  between  samples  [INTVL],  the  number  of  samples  [BLOCKS],  the  number  of 
years  of  sampling  (YRs],  the  sample  mean  [MEAN],  the  sample  variance  [VAR],  the 
covariance  of  the  sample  mean  [2COVAR/N],  the  variance  of  the  sample  mean 
[MEAN. VAR],  the  95  percent  confidence  interval  [C.I.  95%],  and  the  ratio  of  the  Cl 
to  the  sample  mean  expressed  as  a  percent  [%CI/MEAN].  Those  variables  are 
discussed  in  the  "Confidence  Interval”  section  at  the  end  of  this  chapter. 
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The  next  End  of  Run;  PGC  Results  tables  are  duplicates  of  the  PGC  Summary 
Report  table  (Exhibit  4-1)  and  the  PGC  Aggregate  Report  (Exhibit  4-2)  for  the 
current  PGC. 

PGC  NET  STOCK  HISTOGRAM 

After  each  PGC  run,  the  PGC  Net  Stock  histogram  is  displayed  on  the  screen 
(see  Exhibit  4-3).  Net  stock  at  a  point  in  time  is  defined  as  on-hand  inventory  minus 
the  backorders  summed  across  all  NSNs  in  the  PGC.  The  histogram  shows  how  net 
stock  levels  for  the  PGC  vary  over  time. 
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EXHIBIT  4-3.  PGC  NET  STOCK  HISTOGRAM 


The  histogram  intervals  represent  safety-level  units  of  stock  for  the  PGC.  The 
”1”  on  the  X  axis  corresponds  to  the  total  units  of  safety  stock  summed  across  all 
NSNs  in  the  PGC.  For  a  "bag-item”  PGC  (are  items  initially  issued  to  recruits),  for 
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example,  one  unit  of  safety  level  represents  approximately  4.5  months  of  PGC 
demand.  A  value  of  2  or  3  on  the  X  axis  equals  approximately  9  or  13.5  months  of 
demand,  respectively.  The  purpose  of  the  PGC  Net  Stock  histogram  is  to  display  how 
often  net  stock  for  the  PGC  is  above  the  PGC  safety  level,  in  the  safety  level,  or 
negative  (indicating  total  backorders  exceed  total  on  hand  for  the  PGC).  The 
histogram  reflects  net  stock  for  the  PGC.  Positive  net  stock  does  not  imply  that  no 
backorders  exist  —  only  that  total  stock  on  hand  exceeds  total  stock  on  backorder. 
The  purpose  of  the  histogram  is  to  give  picture  of  supply  system  status  over  time  for 
the  PGC  as  a  whole. 

THE  STATISTICAL  ASPECTS  OF  SIMULATION  OUTPUT 

In  this  section,  we  describe  statistical  aspects  of  the  simulation  output  —  how 
confidence  intervals  are  calculated  and  the  reason  for  removing  the  impacts  of  a 
warm-up  period. 

Confidence  Intervals 

Simulations  give  sample  results  —  either  through  replication  or,  as  is  the  case 
with  the  C&T  simulation,  through  the  use  of  long  runs.  For  long  runs,  the  precision 
of  the  output  depends  on  the  length  of  simulated  time  the  model  runs.  The  longer  the 
simulation,  the  larger  the  sample  of  information  and  the  more  precise  the  results. 

C&T  simulation  output  includes  a  95  percent  confidence  interval  estimate  of 
the  average  number  of  outstanding  requisition  backorders  for  the  system.  Given 
data  on  customer  demand,  supply  responsiveness,  and  the  quantitative  levels  used, 
the  C&T  system  will  calculate  an  expected  backorders  value  for  each  PGC.  A 
95  percent  confidence  interval  estimate  means  we  are  95  percent  confident  that  the 
interval  contains  the  true  expected  backorders  for  the  system.  In  general,  the  longer 
the  simulation  runs,  the  smaller  the  confidence  interval.  Confidence  interval 
estimates  of  backorders  are  better  than  point  estimSites  alone  because  they  capture 
the  degree  to  which  outstanding  backorders  can  vary  about  their  average  value. 

A  95  percent  confidence  interval  estimate  of  the  mean  is  defined  as  the  sample 
mean  plus  or  minus  1.96  times  the  square  root  of  the  variance  of  the  sample  mean. 
When  obtaining  samples  through  long  runs,  it  is  necessary  to  account  for  correlation 
of  sample  values  from  one  block  to  the  next.  For  the  correlated  values  from  a  long 


run,  the  variance  of  the  sample  mean  is  the  s\im  of  the  sample  variance  plus  the 
sample  covariance. 


The  simulation  provides  a  confidence  interval  estimate  for  requisition 
backorders  for  each  PGC  run.  A  quick  approximation  of  the  confidence  interval  is 
calculated  every  2  years  (labeled  [QUICK]  in  the  Detail  Trace  Output  report)  and 
recorded  along  with  the  sample  mean,  net  stock,  and  the  ratio  of  the  confidence 
interval  radius  to  the  sample  mean.  The  first  table  of  the  End  of  Run  PGC  Results 
section  of  the  Detail  Trace  Output  Report  displays  the  actual  confidence  interval 
estimate  as  well  as  the  sample  mean  and  variance,  the  covariance  and  variance  of 
the  mean,  and  the  ratio  of  the  confidence  interval  (Cl)  radius  to  the  mean,  expressed 
as  a  percent. 

The  Cl-to-mean  ratio  is  the  key  estimate  of  precision  in  determining  how  long 
to  run  the  simulation.  If  the  ratio  is  large,  200  or  300  percent,  the  simulation  results 
are  correct  only  within  a  factor  of  2  or  3  and  a  longer  simulation  in  years  may  be 
needed.  However,  if  the  Cl-to-mean  ratio  is  20  percent  or  less,  the  simulation  results 
are  fairly  precise.  The  user  must  make  the  tradeoff  between  precision  and  run  time 
in  applications. 

A  few  hundred  years  of  simulated  time  for  a  PGC  can  usually  be  run  overnight. 
Such  runs  usually  yield  Cl-to-mean  ratios  in  the  tens-of-percent  range.  Hard  and 
fast  rules  on  simulation  run  times  do  not  exist.  Appropriate  run  time  depends  on  the 
characteristics  of  the  PGC,  the  time  a  user  is  willing  to  wait  for  results,  and  the 
degree  of  precision  required.  For  policy  analyses  (like  the  C&T  VSL  question),  we 
recommend  a  minimum  run  length  of  200  to  400  years. 

Warm-up  Periods 

A  final  statistical  consideration  is  the  warm-up  period  —  the  initial  period  of 
time  affected  by  the  starting  conditions  of  the  simulation.  At  the  start  of  the  C&T 
simulation,  each  NSN  is  assigned  on-hand  stock  equal  to  its  reorder  point,  has  no 
backorders,  and  has  no  stock  on  order.  To  remove  any  bias  introduced  by  those 
starting  conditions,  the  simulation  is  run  5  years  (the  warm-up  period)  before 
statistical  estimates  of  the  variables  are  taken.  We  assume  that  after  5  years, 


^Covariance  calculations  are  based  on  covariance  equations  in  Donald  Gross  and  Carl  M. 
Harris,  Fundamentals  of  Queueing  Theory,  John  Wiley  &  Sons,  Inc.,  1974,  p.  418. 
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inventory  conditions  (backorders,  stocks  on  hand,  and  stocks  on  order)  have  reached 
levels  that  no  longer  reflect  the  initial  bias  of  the  starting  conditions. 

The  simulation  for  long  runs  was  designed  with  one  warm-up  period  to  save 
processing  time.  Removal  of  the  warm-up  period  each  time  in  a  sequence  of 
repetitive  runs  wastes  processing  time.  With  a  long  run,  the  warm-up  period  need 
only  be  removed  once. 


4-11 


CHAPTERS 


VERIFICATION  AND  VALIDATION 


INTRODUCTION 

This  chapter  reports  the  results  of  some  verification  and  validation  tests 
performed  on  the  C&T  simulation.  In  it,  we  present  evidence  that  the  simulation  is 
working  as  intended  (verification)  and  that  it  can  produce  results  comparable  to 
historical  performance  by  C&T  (validation). 

Verification  and  validation  testing  has  been  performed  continually  throughout 
model  development.  Demonstrations  of  the  simulation  in  protot3rpe  form,  hands-on 
trials,  and  a  formal  validation  session  with  DLA  personnel  have  all  been  part  of  the 
development  effort  as  a  way  to  obtain  user  guidance  and  ensure  that  simulated 
procedures  match  actual  C&T  practice.  This  chapter  will  quantify  and  summarize 
some  of  the  key  aspects  of  the  verification  and  validation  testing. 

In  this  chapter,  we  show  that  input  data  are  read  and  used  correctly,  SAMMS 
inventory  control  procedures  are  followed,  and  on-hand  and  on-order  stock  levels 
generated  in  the  simulation  are  plausible.  We  compare  simulation  results  with 
actual  C&T  results,  discuss  how  and  where  they  match,  and  explain  areas  in  which 
they  do  not.  Some  of  the  verification  and  validation  data  extracted  from  the 
simulation  in  this  chapter  were  obtained  through  the  use  of  approximately  30  trace 
switches  embedded  in  the  model  source  code.  Those  switches  allow  individual 
operations  and  procedures  to  be  independently  exercised,  listed,  and  checked. 

We  examined  data  for  three  PGCs  in  the  verification  and  validation  effort: 
man’s  coat  (PGC  1765),  woman’s  shirt  (PGC  1671), 'and  men’s  and  women’s  gloves 
(PGC  1834).  The  actual  C&T  inventory  data  for  the  three  PGCs  is  taken  from  two 
sources:  Flash  Reports  and  Never-Out  Item  Reports.  Flash  Reports  from  1986  and 
1988  were  used  to  determine  average  monthly  forecasts  (AMF),  average  monthly 
customer  demand  (AMD),  peacetime  acquisition  objectives  (AO),  on-order  stock 
(0/0),  and  peacetime  on-hand  stock  (POS).  The  AO,  0/0,  and  the  POS  levels  are 
expressed  in  months  of  demand  (units  of  stock  divided  by  AMF).  The  Never-Out 
Item  Reports  list  the  requisition  backorders  present  at  the  end  of  the  month.  The 
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Never-Out  Item  Reports  used  are  for  14  months  in  1986  and  1987.  Flash  and  Never- 
Out  Item  Reports  are  produced  monthly  and  contain  NSN-level  information. 

We  generated  simulation  results  based  on  assuming  six  equal  incremental 
deliveries  for  each  NSN.  That  simulation  reflects  the  basic  mode  of  operation  for 
C&T  deliveries  prior  to  the  implementation  of  new  delivery  policies.  Matrix  delivery 
schedules  were  not  in  place  when  the  historical  Flash  and  Never-Out  Item  data  were 
compiled. 

VERIFICATION 

Verification  ensures  that  simulation  code  is  working  as  intended.  In  this 
section,  we  discuss  checks  made  to  ensure  that  proper  input  data  are  used,  SAMMS 
inventory  procedures  are  followed,  and  plausible  results  are  produced  for  on-hand, 
on-order,  and  backorder  estimates.  While  we  performed  verification  analyses  on  all 
three  PGCs,  the  following  discussion  is  limited  to  the  woman’s  shirt  PGC  (1671), 
which  contains  21  NSNs. 

Verification  of  Forecasts 

Are  requirement  forecasts  (including  both  POI  and  QFD  components)  captured 
and  used  correctly  in  the  simulation?  Table  5-1  displays  AMF  data  for  the  21  NSNs 
in  the  woman’s  shirt  PGC.  The  table  lists  the  AMF  data  from  the  February  1988 
Flash  Report  (88060)  and  the  12-month  AMF  captured  from  the  February  1988 
SSCF  Report.  The  ratio  of  the  two  forecasts  is  displayed  in  the  fourth  column.  All 
ratios  are  close  to  100  percent,  which  suggests  that  the  simulation  is  using  the 
correct  SSCF  input,  reading  the  data  correctly,  and  combining  the  POI  and  QFD 
forecasts  correctly  to  obtain  the  total  AMF.  The  two  forecasts  do  not  match  exactly 
because  averages  were  taken  over  slightly  different  time  periods. 

As  discussed  in  Chapter  3,  the  simulation  generates  monthly  forecasts  from  a 
normal  distribution.  The  mean  of  the  distribution  is  the  average  of  the  36-month 
POI  forecast  in  the  input  data  plus  one-third  of  the  QFD  forecast.  Column  5  of 
Table  5-1  —  the  simulation  average  —  displays  the  AMF  after  100  years  of 
simulated  forecasts.  The  simulation  values  are  close  to  Flash  Report  monthly  AMFs 
as  illustrated  by  the  ratios  in  Column  6  of  Table  5U;  that  agreement  indicates  the 
simulation  generates  the  proper  AMF  over  the  course  of  simulated  time. 
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TABLE  5-1 


FORECAST  COMPARISONS 
(Woman's  shirt  PGC) 


-1- 

NSN 

-3- 

SSCF 

1/88 

-4- 

Ratio  (%) 
Flash/SSCF 

-5- 

Simulation 

average 

-6- 

Ratio(%) 

Flash/SIM 

1 

18 

19 

96 

18 

100 

2 

42 

43 

97 

43 

98 

3 

14 

17 

82 

17 

82 

4 

171 

170 

101 

165 

104 

S 

132 

133 

99 

130 

102 

6 

39 

40 

98 

39 

100 

7 

351 

351 

100 

342 

103 

8 

244 

244 

100 

237 

103 

9 

96 

95 

101 

92 

104 

10 

549 

546 

100 

534 

103 

11 

395 

394 

100 

383 

103 

12 

153 

151 

101 

146 

105 

13 

289 

288 

100 

281 

103 

14 

989 

987 

100 

961 

103 

15 

209 

207 

101 

201 

104 

16 

148 

149 

100 

145 

102 

17 

533 

533 

100 

519 

103 

18 

156 

156 

100 

152 

103 

19 

91 

90 

101 

88 

103 

20 

131 

131 

100 

128 

102 

21 

49 

53 

93 

52 

94 

PGC 

4,799 

4,797 

100 

4,673 

102 

Verification  of  SAM  MS  Procedures 

Are  peacetime  acquisition  objectives  (AO)  calculated  correctly?  Though  we  did 
not  separately  test  individual  SAMMS  factors  produced  in  the  model,  we  did  test  the 
sum  of  several  critical  SAMMS  factors:  the  safety  level,  the  administrative  and 
production  leadtime,  and  procurement  cycle  period  (PCP). 

For  the  woman’s  shirt  PGC,  all  21  NSNs  have  safety  levels  of  4.5  months  and 
total  leadtimes  of  15.7  months  of  demand.  The  PCP  is  NSN-specific  and  is  displayed 


in  Column  2  of  Table  5-2.  Columns  3  and  4  display  the  AOs  from  the  simulation  and 
the  Flash  Report,  respectively.  The  two  sets  of  AOs  match  exactly  for  most  NSNs, 
differing  only  slightly  on  four  items.  This  suggests  that  the  simulation  is  calculating 
safety  level,  production  leadtime  (PLT),  administrative  leadtime,  and  PCP  correctly. 
The  only  explanation  for  the  four  NSNs  that  fail  to  match  is  that  manual  overrides 
were  present  in  the  SAMMS  data  picked  up  in  the  Flash  Reports. 

TABLE  5-2 

ACQUISITION  OBJECTIVES  AND  STOCK  LEVELS 
(Woman's  shirt  PGC  in  months) 


-1  - 

NSN 

Acquisition  objective 

Average  asset  position  (AP) 

-9- 

On- 

order 

stock 

Simulation 

H 

-5- 

Oelta 
Flash - 
SIM 

-6- 

Adjusted 

AO 

-7- 

OHt-OR 

-BO 

SIM 

-8- 

Ratio(%) 

AO/AP 

-2- 

PCP 

H 

1 

12 

32 

32 

0 

31 

28 

109 

7 

27 

28 

- 1 

26 

27 

96 

mam 

12 

32 

32 

0 

31 

29 

107 

18.0 

6 

26 

26 

0 

25 

26 

95 

17.9 

6 

26 

26 

0 

25 

24 

102 

18.0 

8 

28 

28 

0 

27 

26 

102 

18.1 

6 

26 

26 

0 

25 

25 

99 

17.8 

6 

26 

26 

25 

25 

101 

17.9 

9 

6 

26 

26 

0 

25 

25 

101 

18.1 

10 

6 

26 

27 

- 1 

25 

25 

100 

18.0 

11 

6 

26 

26 

0 

25 

25 

101 

17.9 

12 

6 

26 

26 

0 

25 

24 

101 

18.0 

13 

6 

26 

27 

-1 

25 

26 

96 

18.0 

14 

6 

26 

26 

0 

25 

25 

100 

17.9 

15 

6 

26 

26 

0 

25 

25 

101 

17.9 

16 

6 

26 

26 

0 

25 

25 

100 

18.0 

17 

6 

26 

26 

0 

25 

25 

100 

17.9 

18 

6 

26 

26 

0 

25 

25 

101 

18.0 

6 

26 

27 

-1 

25 

25 

99 

18.0 

6 

26 

26 

0 

25 

25 

100 

18.0 

7 

27 

27 

0 

26 

26 

100 

18.0 

PGC 

25 

25 

100 

17.9 

Verification  of  Simulated  Stock  Levels 


Do  stock  levels  generated  by  the  simulation  behave  consistently  and  correctly? 
Given  the  input  data  and  the  rules  the  C&T  Directorate  follows,  we  can  make 
general  estimates  on  what  the  stock  levels  should  be.  In  this  section,  we  examine  the 
consistency  of  total  stock  levels,  on-order  stock,  and  negative  stock  (backorders)  from 
an  inventory-theoretic  perspective. 

The  AO  may  be  thought  of  as  the  maximum  asset  position  (on  order  plus  on 
hand  minus  backorders)  that  can  occur  at  any  time  in  the  simulation.  The  average 
asset  position  for  an  NSN  should  be  less  than  the  AO  by  an  amount  dependent  upon 
the  POP  and  the  average  number  of  replenishment  orders  per  year.  For  example,  the 
asset  position  for  an  item  with  a  6-month  POP  and  averaging  two  orders  per  year 
would  usually  fluctuate  between  the  AO  and  the  AO  minus  6  months.  An 
approximate  average  asset  position  average  would,  therefore,  be  the  AO  minus 
3  months.  For  the  woman’s  shirt  PGC,  an  average  of  4.45  orders  per  year  are  placed, 
so  the  adjustment  to  the  AO  is  1.34  months  for  NSNs  with  a  POP  of  6  months.  The 
AO  minus  that  adjustment  should  approximate  the  average  asset  position  in  the 
simulation.  Table  5-2  displays  each  NSN’s  AO  minus  the  1.34-month  adjustment, 
the  average  asset  position  generated  by  the  simulation,  and  the  ratio  of  the  two 
levels.  For  most  NSNs,  the  adjusted  simulated  AO  agrees  with  the  simulated  asset 
position.  This  is  evidence  that  stock  levels  in  the  simulation  are  being  correctly 
computed. 

Another  test  is  to  compare  on-order  stocks  (in  months  of  demand)  to  leadtime. 
In  general,  the  amount  of  stock  on  order  should  agree  with  the  average  leadtime  for 
the  item.  In  the  simulation,  the  leadtime  for  the  woman’s  shirt  PGC  is  15.7  months. 
The  average  supplier  delay  over  the  course  of  the  simulation  is  1.8  months.  Thus, 
the  total  leadtime  is  17.5  months.  The  last  column  in  Table  5-2  displays  the  average 
on-order  stock  in  months  from  a  100-year  run.  For  the  21  NSNs  in  the  PGC,  on-order 
stock  ranged  from  17.8  to  18.2  months,  agreeing  well  with  the  expected  value  of 
17.5  months. 

Are  backorder  calculations  correctly  performed?  Time-weighted  backorders 
are  the  most  important  estimate  of  inventory  performance.  They  are  also  the  most 
difdcult  measure  to  verify  and  validate  in  the  simulation  because  backorders  tend  to 
occur  infrequently  and  are  usually  small  in  relation  to  demand  and  asset  position. 
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They  tend  to  occtir  only  under  extreme  conditions.  One  way  to  verify  backorder 
estimates  is  to  calculate  them  in  two  different  ways  and  test  the  results  for 
agreement.  The  first  way  is  to  track  each  backorder  as  it  occurs  and  record  how  long 
it  lasts.  From  that  information,  it  is  possible  to  compute  the  time-weighted  average 
of  outstanding  backorders.  The  ’’accumulate”  feature  in  SIMSCRIPT  computes  that 
average  automatically.  The  second  way  is  to  sample  backorders  at  constant 
intervals  throughout  the  simulation  and  compute  the  sample  average.  Both 
approaches  yield  nearly  identical  results  (within  1  or  2  percent)  for  unit  and 
requisition  average  backorders. 

The  preceding  verification  evidence  indicates  that  the  simulation  code  is 
performing  as  intended. 

VALIDATION 

This  section  compares  simulation  results  with  historical  C&T  inventory 
information  from  Flash  and  Never-Out  Item  Reports  to  obtain  preliminary  evidence 
on  the  validity  of  the  simulation.  For  definitive  validation,  we  must  examine  more 
PGCs,  with  more  historical  data,  over  longer  periods  of  time.  Nevertheless,  the 
results  presented  here  suggest  the  simulation  is  able  to  approximate  real-world  C&T 
performance  at  the  PGC  level.  We  start  with  a  discussion  of  how  well  the  simulation 
is  able  to  reproduce  real-world  forecasting  and  demand  processes. 

Forecast  and  Demand  Validation 

In  this  section,  we  focus  on  trends  in  historical  forecasts  and  actual  demands 
over  time.  We  compare  historical  forecasts  with  actual  demands  and  examine  how 
well  the  simulation  reflects  forecast  and  demand  trends.  We  also  suggest  steps  that 
can  be  taken  to  better  integrate  and  improve  simulation  results  and  data  collection 
efforts. 

Historical  Forecasts  and  Demands 

A  key  observation  of  the  validation  effort  is  that  all  three  PGCs  studied  exhibit 
significant  decreases  in  AMF  from  1986  to  1988.  For  the  woman’s  shirt  PGC,  the 
AMF  at  the  PGC  level  decreased  from  5,641  in  1986  to  4,321  in  1988,  making  the 
1986  PGC  forecast  131  percent  of  the  1988  forecast.  In  other  words,  1988  forecasts 
were  31  percent  smaller  than  1986  forecasts.  The  gloves  and  coats  PGCs  showed 
similar  trends  although  the  percentage  decline  is  approximately  half  that  of  the 
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woman’s  shirt  PGC.  This  declining  forecast  trend  is  even  more  pronounced  at  the 
NSN  level.  Table  5-3  displays  the  1986- to- 1988  AMF  ratios  for  each  size  fNSN)  of 
woman’s  shirt.  Some  ratios  are  as  great  as  460  percent. 

TABLE  5<3 

FLASH  FORECASTS  FOR  1986  AND  1988 
(Woman's  shirt  PGC  in  units) 


NSN 

AMF 

Ratio  (%) 
1986/1988 

Average  1986 

Average  1988 

1 

52 

17 

302 

2 

145 

45 

324 

3 

67 

14 

468 

4 

146 

165 

88 

5 

419 

124 

337 

6 

173 

37 

464 

7 

278 

297 

93 

8 

531 

220 

242 

9 

238 

89 

267 

10 

313 

452 

69 

11 

801 

374 

214 

12 

340 

131 

260 

13 

279 

260 

107 

14 

619 

869 

71 

15 

442 

188 

235 

16 

80 

165 

48 

17 

265 

472 

56 

18 

312 

142 

219 

19 

47 

98 

47 

20 

67 

114 

59 

21 

32 

47 

66 

PGC 

5,641 

4,321 

131 

Like  AMF,  the  AMD  also  declined  from  4,731  in  1986  to  3,565  in  1988,  making 
a  1986-to-1988  ratio  of  132  percent.  The  gloves  and  coats  PGCs  showed  similar 
declines,  but  the  ratios  were  closer  to  100  percent.  The  interesting  aspect  of  the 
AMD  trend  is  how  it  compares  with  the  AMF  trend.  For  all  three  PGCs,  the  AMF-to- 
AMD  ratios  from  1986  to  1988  were  greater  than  100  percent  both  at  the  PGC  level 
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and  for  the  majority  of  NSNs.  A  general  tendency  in  the  POI  system  to  overforecast 
customer  demand  is  also  noted  in  a  1985  DLA  study, ^  that  reported  61  percent  of  the 
300  POI  PGCs  studied  exhibited  overforecasted  demand. 

The  tendency  to  overforecast  is  consistent  over  time  at  the  NSN  level.  The 
1986  AMF-to-AMD  ratios  strongly  correlate  with  those  for  1988.  For  the  woman’s 
shirt  PGC,  the  sample  correlation  coefficient  is  0.97.  The  man’s  coat  PGC  also 
exhibits  a  strong  AMF-to-AMD  ratio  correlation  over  time,  with  a  sample 
correlation  coefficient  of  0.83.  The  correlation  coefficient  for  men’s  and  women’s 
gloves  is  lowest  at  0.34. 

In  summary,  three  key  observations  can  be  made  about  historical  AMFs  and 
AMDs  for  the  three  PGCs  examined:  (1)  the  AMF  declined  significantly  from  1986  to 
1988,  (2)  the  tendency  is  to  overforecast  customer  demand,  and  (3)  the  ratios  of  AMF 
to  AMD  are  correlated  over  time  at  the  NSN  level.  As  we  discuss  next,  these  three 
conditions  must  be  taken  into  account  in  attempting  to  validate  the  simulation. 

Simulation  Results 

Regarding  the  problem  of  trends,  the  model  cannot  simulate  a  trend  in 
forecasts  similar  to  that  which  occurred  from  1986  to  1988.  The  current  forecasting 
process  generates  a  requirements  array  that  rolls  forward  in  simulated  time  but  is 
still  always  a  reflection  of  the  single  requirements  forecast  in  the  input  data.  To 
simulate  trending  forecasts  it  would  be  necessary  to  develop  a  ”short-run-with- 
replications”  version  of  the  simulation.  It  is  not  clear  what  such  a  capability  would 
accomplish,  however.  Presumably  DLA  is  interested  in  simulating  forecasting 
trends  in  order  to  determine  how  they  affect  supply  performance.  Simulation, 
however,  is  not  the  best  tool  for  measuring  such  transient  effects.  A  better  approach 
would  be  to  analyze  historical  performance  data  from  periods  for  which  forecast 
trends  existed  and  from  that  analysis  develop  empirical  rules  on  how  trends  in 
forecasts  are  likely  to  affect  stockage  requirements  and  performance  in  the  future. 

The  user  can  adjust  the  simulation  to  mimic  the  tendency  to  overforecast.  At 
the  PGC  level,  the  simulation  has  a  demand  control  knob  to  adjust  the  AMD  to  make 
it  less  than  or  greater  than  the  AMF.  For  the  woman’s  shirt  PGC,  the  1988 


IS.  Orchowsky,  Report  on  Analysis  of  the  Program  Oriented  Item  System  for  Forecasting 
Clothing  Items,  Operations  Research  and  Economic  Analysis  Office,  Headquarters  DLA,  Jan  1985. 
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AMD-to-AMF  ratio  is  0.82  (3,565  divided  by  4,321).  To  incorporate  this  overforecast 
tendency  into  the  simulation,  the  demand  knob  may  be  set  at  0.82.  This  adjustment 
affects  all  NSNs  in  the  PGC  equally,  so  that  the  AMD  on  average  will  be 
approximately  18  percent  less  than  the  AMF  for  the  PGC  as  a  whole. 

The  third  observation  about  historical  forecasts  and  demands,  that  AMD-to- 
AMF  ratios  are  correlated  over  time,  suggests  that  the  demand-generating  process 
in  the  simulation  could  possibly  be  improved  by  incorporating  forecasting  bias  in  the 
form  of  empirical  forecast-to-demand  ratios.  This  suggestion  is  discussed  further  in 
Chapter  7. 

Before  comparing  simulation  results  to  Flash  Report  values  at  the  NSN  level, 
another  point  must  be  made  about  simulation  results  alone.  Table  5-4  displays  the 
AMF  and  the  AMD  generated  by  the  simulation  for  the  woman’s  shirt  PGC  with  a 
demand  knob  setting  of  1.  Table  5-4  also  displays  the  simulated  AMF-to-AMD  ratio. 
The  table  shows  the  simulation  may  tend  to  underforecast  demand  (AMF-to-AMD 
ratios  less  than  100  percent). 

An  underforecast  bias  exists  in  the  simulation  because  demands  are  drawn 
from  a  normal  distribution  that  has  as  its  mean  the  monthly  forecast  and 
(1.25  X  MAD)  as  its  standard  deviation.  Underforecasting  occurs  when  an  NSN  has 
a  very  large  MAD  in  relation  to  its  mean.  The  larger  the  MAD,  the  greater  chance 
that  the  value  drawn  from  the  normal  distribution  will  be  negative.  Since  negative 
demands  do  not  make  sense,  the  simulation  truncates  all  negative  values  and  sets 
them  equal  to  1.  That  truncation  unbalances  the  symmetry  of  the  normal 
distribution,  and  the  AMD  becomes  larger  than  the  AMF.  Thus,  when  MAD  is  large 
relative  to  the  mean  forecast,  the  simulation  has  a  tendency  to  underforecast 
demand. 

Mean  Absolute  Deviation 

The  preceding  discussion  raises  the  separate  and  important  question:  why  are 
MADs  for  POI  items  so  large?  We  believe  the  problem  is  that  for  POI  items,  MAD  is 
not  keeping  pace  with  changing  forecasts.  Table  5-3  shows  that  from  1986  to  1988, 
forecasts  declined  significantly.  For  NSN  3,  for  example,  the  1986-to-1988  ratio  is 
468  percent.  The  MAD  in  the  SSCF  input  data  for  NSN  3  is  36.3.  The  absolute 
deviation,  however,  between  the  AMF  and  the  AMD  for  1986  and  1988,  respectively, 
is  18  and  6.  At  36.3,  the  NSN  3  MAD  is  much  greater  than  it  should  be  based  on 


5-9 


TABLE  5-4 


SIMULATION  FORECASTS  AND  DEMANDS 
(Woman's  shirt  PGC  in  units) 


NSN 

AMF 

AMD 

%  AMF/AMD 

1 

18 

25 

74 

2 

43 

59 

72 

3 

17 

28 

60 

4 

165 

167 

99 

5 

129 

164 

79 

6 

39 

55 

71 

7 

342 

342 

100 

8 

236 

270 

88 

9 

92 

114 

81 

10 

535 

538 

99 

11 

382 

421 

91 

12 

146 

181 

81 

13 

282 

284 

99 

14 

955 

959 

100 

15 

200 

226 

89 

16 

146 

155 

94 

17 

520 

524 

99 

18 

151 

167 

91 

19 

88 

95 

93 

20 

127 

132 

97 

21 

52 

58 

90 

PGC 

4,667 

4,964 

94 

experience  in  1986  and  1988.  When  the  MAD  of  36.3  is  used  in  the  simulation,  the 
demands  for  NSN  3  are  drawn  from  a  normal  distribution  that  has  a  standard 
deviation  2.7  times  larger  than  the  mean  (AMF).  'As  a  result,  NSN  3  is  the  most 
underforecasted  NSN  in  the  PGC  (AMF-to- AMD  ratio  of  60  percent  in  Table  5-4). 
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MADs  can  be  large  when  current  deviations  are  small  because  of  the  way  MAD 
is  calculated.  The  formula  for  MAD  weights  and  averages  the  deviations  (forecast 
minus  demand)  from  all  previous  time  periods: 

t-i 

MAD(t)  =  y  ALPHA  X  (1  -  ALPHA)‘“‘  X  rlAMF(n  -  AMD(i)|], 

1=0 

where: 

i  =  past  time  periods  (months  for  VIP  items  and  quarters  for  non- VIP 

items) 

t  =  the  current  time  period 

ALPHA  =  the  alpha  factor  (0.05  for  VEP  items  and  0.15  for  non- VEP  items). 

The  influence  (or  weight)  of  the  deviation  in  any  particular  time  period,  i,  depends  on 
how  close  that  period  is  to  the  present  time,  t: 

WEIGHT  (i)  =  ALPHA  X  (1  -  ALPHA)‘‘"‘\ 

For  VIP  items,  Table  5-5  displays  the  weights  associated  with  data  from 
different  periods.  Data  that  are  1  year  old  determine  46  percent  of  the  MAD  value. 
Data  that  are  2  years  old  determine  25  percent  of  the  MAD  value.  Data  that  are  3  to 
8  years  old  determine  the  remaining  29  percent  of  the  MAD  value. 

TABLE  5-5 

MAO  COMPOSITION:  PERCENT  WEIGHTING 
AND  AGE  OF  DATA 


Age  of  data 
(years) 

VIP  items  (%) 

Alpha  a  0.05 

Corrective 
Alpha  a  0.10 

1 

46 

72 

2 

25 

20 

3 

13 

5 

5-8 

16 

3 

MAD  may  not  be  keeping  pace  with  current  forecasting  trends  because  a 
significant  part  of  its  value  (29  percent)  is  determined  by  forecasts  that  may  be  very 


5-11 


different  from  current  forecasts.  The  problem  is  exacerbated  when  forecasts  are 
trending  down.  The  magnitude  of  the  absolute  deviation  for  old,  large  forecasts  will 
be  greater  than  that  of  more  recent  deviations  even  though  relative  deviations 
[Deviation  (i)  divided  by  the  AMF  (i)]  may  be  similar.  Thus,  large  deviations  from 
the  past  may  be  making  current  MADs  too  big. 

A  way  to  make  MAD  a  more  accurate  estimator  of  current  forecast  error  is  to 
use  corrective  alpha  values  (assigned  to  C&T  items)  to  calculate  MAD.  Table  5-5 
displays  C&T  corrective  alphas.  The  corrective  alpha  is  twice  as  large  as  the  regular 
alpha  and  gives  greater  weight  to  more  recent  data.  With  the  corrective  alpha,  the 
most  recent  data  (aged  2  years  or  less)  define  virtually  all  (92  percent)  of  the  MAD 
value. 

Simulation  Results  Versus  Historical  Data 

The  final  validation  step  for  forecasts  and  demands  is  to  compare  simulation 
AMF-to-AMD  ratios  with  historical  ratios  at  the  NSN  level.  Table  5-6  displays  three 
different  AMF- to- AMD  ratios  expressed  as  a  percent:  the  first  from  a  Flash  Report 
for  the  first  quarter  in  1988,  the  second  from  a  Flash  Report  in  1986,  and  the  last 
from  the  simulation.  The  two  Flash  Report  ratios,  although  not  identical,  are 
strongly  correlated  (a  sample  correlation  coefficient  of  0.975).  The  simulation  ratios 
in  Table  5-6  were  obtained  after  adjusting  the  demand  knob  so  that  at  the  PGC  level, 
the  simulation  matched  the  PGC  ratios  from  the  Flash  Reports.  Even  with  that 
adjustment,  simulation  ratios  at  the  NSN  level  are  not  well  correlated  with  Flash 
Report  ratios.  Even  when  MADs  are  calculated  with  corrective  alphas,  eliminating 
the  simulation’s  tendency  to  underforecast,  forecast-to-demand  ratios  at  the  NSN 
level  may  still  not  correlate  well  with  historical  ratios. 

The  problem  is  that  MAD  in  the  DLA  system  is  designed  for  QFD  items  and  is 
not  well-suited  as  an  estimator  of  demand  variance  for  POI  items.  For  pure  QFD 
items,  historical  data  are  the  basis  for  forecasts  and  over-  or  underforecast 
tendencies  are  naturally  corrected.  For  POI  items,  forecasts  are  not  linked  to 
historical  demand  and  no  natural  mechanism  for  corrective  action  occurs.  To  obtain 
better  NSN-level  realism  in  the  simulation  would  require  the  use  of  additional  data, 
supplementing  MAD,  that  provided  insight  on  NSN-level  forecasting  tendencies  by 
NSN. 
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TABLE  5-6 


FORECAST -TO-OEMAND  RATIOS 
[Woman's  shirt  PGC  (percent)] 


NSN 

%  AMF/AMO 

Flash  1988 

Flash  86120 

Simulation 

1 

204 

131 

84 

2 

201 

132 

79 

3 

190 

127 

67 

4 

107 

113 

118 

5 

140 

117 

88 

6 

162 

117 

78 

7 

108 

110 

124 

8 

127 

116 

102 

9 

132 

113 

91 

10 

105 

111 

125 

11 

119 

114 

107 

12 

121 

113 

90 

13 

107 

110 

123 

14 

109 

114 

125 

15 

110 

112 

106 

16 

106 

109 

115 

17 

112 

117 

123 

18 

115 

111 

108 

19 

132 

140 

109 

20 

112 

119 

117 

21 

563 

270 

112 

PGC 

115 

115 

114 

The  simulation  could  be  modified  in  three  different  ways  to  compensate  for 
over-  or  underforecasting  tendencies  at  the  NSN  level.  The  first  way  would  be  to  use 
Flash  Report  AMF-to-AMD  ratios  for  several  years.  From  those  ratios,  an  NSN- 
specific  empirical  distribution  could  be  constructed  and  used  in  the  simulation. 
Flash  Report  data  are  the  most  complete,  but  additional  programs  would  be  required 
to  automate  the  transfer  of  the  Flash  Report  data  to  the  simulation.  However,  if 
Flash  Report  data  from  one  year  to  the  next  are  correlated,  as  the  initial  analysis 
suggests,  they  might  not  have  to  be  transferred  very  often. 
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Another  possible  way  to  incorporate  NSN-specific  forecasting  trends  into  the 
simulation  would  be  to  use  the  algebraic  sum  of  forecast  error  (ASFE)  data  element 
from  the  SSCF  input  file.  The  sign  and  magnitude  of  the  ASFE  determine  the 
amount  of  under-  or  overforecasting  that  occurs  on  average.  The  ASFE  is  available 
to  the  simulation  in  the  SSCF  file  and  would  not  require  additional  transfer 
programs.  However,  the  ASFE  procedures  in  SAMMS  should  be  changed  so  that 
ASFE  is  set  to  zero  more  frequently.  If  not,  like  the  MAD,  it  may  be  biased  by  old 
data. 


The  final  possibility  would  be  to  use  SSCF  historical  demand  data  and  the 
current  forecast  to  obtain  a  simple  approximation  of  whether  under-  or 
overforecasting  is  occurring  at  the  NSN  level.  Again,  this  information  is  readily 
available  to  the  simulation.  However,  demand  data  are  only  for  1  year  (4  quarters), 
the  forecast  data  are  for  only  1  quarter,  and  demands  and  forecast  apply  to  slightly 
different  time  periods. 

Inventory  Level  Validation 

We  now  turn  to  the  simulation’s  ability  to  match  real-world  inventory  levels. 
C&T  simulation  results  are  basically  estimates  of  average  inventory  levels  over 
time.  This  section  compares  inventory  levels  from  the  simulation  with  historical 
C&T  levels.  We  first  examine  on-hand  inventory  levels,  then  on-order  inventory  as  a 
proportion  of  total  inventory,  and  finally  requisition  backorders. 

Data  on  the  on-hand  inventory  considered  come  from  the  1988  Flash  Report. 
Table  5-7  displays  1988  peacetime  on-hand  inventory  (expressed  in  months  of 
forecasted  demand)  for  the  woman’s  shirt  PGC.  Almost  half  the  NSNs  in  that  PGC 
have  on-hand  stock  values  of  40  months  or  more.  Those  values  are  surprisingly  large 
considering  most  of  the  NSNs  have  peacetime  acquisition  objectives  of  26  months. 
The  NSNs  with  the  large  on-hand  inventory  are  the  NSNs  with  high  1986- to- 1988 
AMF  ratios.  What  has  happened  is  that  in  1986,  when  the  order  was  placed  for  what 
was  to  become  on-hand  stock  in  1988,  the  AMF  was  much  larger  than  it  was  when 
the  order  was  actually  received  a  leadtime  later.  The  average  on-hand  stock  at  the 
PGC  level  is  13.5  months  in  the  1988  Flash  Report.  In  the  1986  Flash  Report,  the 
average  on-hand  stock  for  the  PGC  is  only  6.9  months,  a  value  closer  to  the 
simulation  estimate  of  6.3  months.  Thus,  we  conclude  that  the  simulation  estimates 
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for  on-hand  stock  will  be  relatively  close  to  actual  on-hand  stock  averages  as  long  as 
strong  trends  are  not  present  in  the  forecasts. 


TABLE  5-7 

ON-HANO  PEACETIME  OPERATING  STOCK 
[Woman's  shirt  PGC  in  months  (units/AMF)] 


NSN 

Flash  Report  for  1988 

Flash 

%  1986/1988 
AMF 

88152 

88121 

88091 

88060 

88031 

1 

48 

49 

49 

49 

50 

302 

2 

42 

43 

43 

46 

46 

324 

3 

48 

49 

49 

50 

48 

468 

4 

7 

7 

6 

8 

8 

88 

5 

47 

48 

47 

48 

49 

337 

6 

51 

52 

52 

52 

53 

464 

7 

7 

7 

7 

7 

7 

93 

8 

45 

46 

45 

45 

46 

242 

9 

43 

44 

44 

44 

45 

267 

10 

8 

8 

8 

7 

7 

69 

11 

31 

29 

24 

26 

27 

214 

12 

46 

47 

46 

45 

46 

260 

13 

8 

8 

6 

8 

8 

107 

14 

7 

2 

2 

2 

3 

71 

15 

44 

45 

42 

40 

41 

235 

16 

0 

0 

0 

0 

0 

48 

17 

0 

0 

0 

0 

2 

56 

18 

29 

29 

24 

24 

24 

219 

19 

0 

0 

1 

0 

0 

47 

mSM 

2 

2 

2 

2 

2 

59 

5 

5 

4 

5 

4 

66 

PGC 

518 

520 

501 

508 

516 

131 

We  next  consider  on-order  percentages:  the  ratio  of  on-order  stocks  to  the  sum 
of  on-order  and  on-hand  stocks.  The  percentage  measure  allows  us  to 
simultaneously  consider  both  on-hand  and  on-order  inventory.  We  compare  the  on- 
order  percentage  from  the  simulation  with  that  in  the  1988  Flash  Reports  for  all 
three  PGCs  in  Table  5-8.  The  simulation  results  are  relatively  close  to  the  historical 
data  in  the  1988  Flash  Reports  with  the  exception  of  the  woman’s  shirt  PGC.  The 
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large  on-hand  values  for  that  PGC,  already  discussed,  explain  why  the  Flash  Report 
on-order  percentages  are  low.  (In  1986,  the  on-order  percentage  for  the  woman’s 
shirt  PGC  was  73  percent,  as  opposed  to  27  percent  in  1988.) 


TABLE  5-8 

PGC  ON-OROER  PERCENT: 
SIMULATION  VERSUS  HISTORICAL  DATA 

[On  order/(on  order  '<■  on  hand)] 


PGC 

Simulation 

{%) 

Flash 

Report  (%) 
1988 

Woman's  shirt 

62 

27 

Men's  and  women's  gloves 

49 

35 

Man's  coat 

61 

85 

A  key  driver  of  on-order  stock  levels  is  the  actual  leadtime  for  the  PGC. 
However,  historical  data  on  actual  leadtime  delays  are  very  limited;  no  MAD  is 
available  for  leadtimes,  for  example.  The  only  information  available  is  Control  Line 
Item  Number  (CLIN)  Delinquency  Report  information,  and  it  is  neither  NSN-  or 
PGC-specific,  but  applies  across  all  C&T  PGCs.  To  compensate  for  the  lack  of 
historical  data,  the  simulation  provides  a  PLT  control  knob  for  increasing  or 
decreasing  leadtime  delays.  For  items  such  as  coats,  where  the  simulation  on-order 
percentage  is  less  than  the  Flash  Report  percentage,  the  average  delay  for  coats  is 
likely  to  be  greater  than  the  overall  average  delay  of  55  days  shown  in  the  CLIN 
data.  (Coats,  in  particular,  have  been  a  troublesome  item  for  the  C&T  Directorate  in 
1988.)  To  reflect  that  situation,  the  user  can  increase  the  PLT  by  moving  the  PLT 
knob  to  a  value  greater  than  1.  On  the  other  hand,  for  men’s  and  women’s  gloves,  the 
user  can  decrease  the  PLT  to  reduce  the  simulation  on-order  percentage. 

We  turn  finally  to  backorders  and  supply  availabilities.  Backorders  are  the 
most  difficult  to  validate  because  of  their  relative  scarcity,  at  least  for  POI  items. 
Definitive  backorder  validation  is  difficult  without  more  extensive  historical  data. 

Historical  backorder  estimates  are  drawn  from  14  months  of  C&T  Never-Out 
Item  Reports,  which  give  a  snapshot  of  the  backorder  status  at  the  end  of  the  month. 
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No  average  quarterly  or  annual  values  are  available.  Table  5-9  compares  the 
requisition  backorders  from  the  simulation  with  the  historical  Never-Out  Item 
Report  data  for  the  three  PGCs.  In  Table  5-9,  the  demand  knob  for  the  simulation 
has  been  adjusted  to  match  the  historical  AMF-to-AMD  ratios,  but  no  a4iustment  of 
the  PLT  knob  has  been  made.  Table  5-9  demonstrates  that  simulation  values  are 
close  for  gloves,  high  for  shirts,  and  low  for  coats.  The  differences  exist  for  a  number 
of  reasons.  Simulation  backorder  estimates  for  the  woman’s  shirt  PGC  are  probably 
too  high  because  of  the  overestimation  of  MAD.  Men’s  coat  backorders  may  be  too 
low  because  PLT  delays  may  be  too  low  (suggested  by  the  on-order  percentage  in  the 
simulation  being  less  than  the  historical  percentage). 

In  general.  Table  5-9  demonstrates  that  simulation  results  are  the  same  order 
of  magnitude  as  historical  values.  However,  until  more  detailed  data  are  available, 
the  user  may  have  to  calibrate  the  simulation  in  order  to  closely  duplicate  real-world 
results. 


TABLE  5-9 

REQUISITION  BACKORDERS  AND  SUPPLY  AVAILABILITIES 


PGC 

95%  confidence  intervals  for 
requisition  backorders 
(units) 

Requisition  supply 
availabilities 
(%) 

Simulation 

Average 
19B6/1988 
Never-Out 
Item  Report 

Simulation 

Average 
1986/1987 
Never-Out 
Item  Report 

Woman's  shirt 

100  ±  17 

21  ±  10 

90.3 

96.4 

Men's  and  women's  gloves 

34  ±  7 

31  ±  24 

97.9 

94.3 

Man's  coat 

23  ±  9 

128  ±112 

99.1 

95.1 

CONCLUSIONS 

In  this  chapter,  we  have  covered  a  variety  of  verification  and  validation  results. 
In  general,  the  verification  results  demonstrate  that  the  model  is  capturing  data 
correctly,  following  SAMMS  procedures  for  determining  levels  correctly,  and 
producing  results  that  reflect  the  basic  structure  of  the  C&T  inventory  process.  A.t 
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the  PGC  level,  model  results  agree  reasonably  well  with  historical  values,  after 
adjusting  for  significant  trends  and  variability  in  the  historical  data. 

The  greatest  strength  and  the  most  likely  application  of  the  model  is  to  draw 
conclusions  from  separate  passes:  a  baseline  pass  with  no  policy  change  and  a  test 
pass  with  a  policy  change.  Model  biases  would  be  similar  and  should  not  influence 
the  "delta”  arising  from  the  policy.  The  effect  of  policy  changes  can  be  estimated, 
therefore,  even  if  model  results  do  not  replicate  real-world  performance. 

The  weaknesses  of  the  model  are  its  inability  to  estimate  the  effects  of  trends 
and  to  identify  differences  at  the  NSN  level.  We  have  suggested  modifications  to 
overcome  those  weaknesses  if  DLA  desires  to  analyze  trends  or  NSN  levels. 

Input  data  are  important  for  any  model.  More  data  analysis  could  and  should 
be  done,  and  the  collection  of  historical  data  should  be  improved.  An  easy 
improvement  would  be  to  use  the  corrective  alpha  for  POI  items  so  that  the  MAD  for 
those  items  keeps  pace  with  changing  forecasts.  Another  improvement  would  be  to 
develop  and  collect  PGC-  or  NSN-level  estimates  on  leadtime  delay  and  variability. 
A  third  improvement  would  be  to  collect  and  estimate  average  backorders  on  an 
annual  or  quarterly  basis.  However,  the  most  important  improvement  would  be  to 
combine  Flash  Reports  and  Never-Out  Item  Reports  into  a  single  computerized  data 
base,  preferably  PC-based.  By  combining  stock  levels  with  backorder  estimates,  a 
more  complete  inventory  picture  could  be  obtained.  With  a  computerized  data  base 
(as  opposed  to  the  present  hard-copy  medium),  essential  data  analyses  could  be 
performed  and  results  quickly  incorporated  into  the  simulation. 
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CHAPTER  6 


OPERATING  INSTRUCTIONS 


INTRODUCTION 

This  chapter  steps  through  the  process  of  running  the  C&T  simulation.  It 
starts  with  the  log-on  procedure,  displays  and  explains  the  queries  used  to  configure 
the  model,  and  describes  how  to  manipulate  input  and  output  files.  In  it,  we  discuss 
the  SIMSCRIPT  commands  for  transferring  sections  of  input  and  output  files  to  a 
spreadsheet  program  (LOTUS  1-2-3). 

The  interactive  queries  that  begin  a  model  run  can  be  submitted  in  minutes. 
They  allow  a  user  to  change  model  inputs  and  configure  the  model  for  different 
applications.  The  exhibits  in  this  chapter  display  the  step-by-step  responses 
required  to  run  the  simulation  as  they  actually  appear  on  a  monitor  screen.  The 
underlined  responses  must  be  entered  through  the  keyboard.  An  "[R]”  signifies 
pressing  the  Return  or  Enter  key. 

LOGGING  ON  TO  SIMSCRIPT 

After  turning  the  PC  and  monitor  on,  perform  the  following: 

r  ^ 

C;>CD\SIM  [Rl 
C : >\S1M>SIMLAB  fRi 
S IMLAB >SELECT  DLA  fRl 


EXHIBIT  6-1.  LOGGING  ON  TO  SIMSCRIPT 
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The  first  command  in  Exhibit  6-1  changes  the  directory  from  the  root  to  the 
SIMSCREPT  directory;  the  second  calls  the  SIMLAB  software  of  SIMSCRIPT,  The 
final  command  accesses  the  C&T  simulation  system. 

[Note:  At  this  point,  the  user  is  able  to  run  the  C&T  simulation  by  entering; 
SIMLAB  >  RUNFRI.  If,  however,  SSCF  reports  for  the  NSNs  to  be  simulated  have 
not  yet  been  processed  by  the  capture  program,  the  user  should  first  type  SELECT 
DLADATA  and  run  the  capture  program  (see  Appendix  C).  Also  at  this  point,  if 
VSLs  are  to  be  used  in  the  run  and  have  not  already  been  computed,  the  user  can 
type  SELECT  VSL  to  access  the  VSL  model  (see  Appendix  D).] 

INTERACTIVE  QUERIES 

This  section  displays  and  explains  each  model  query. 

SIMLAB>R1JW  fRI 

1)ENTER  |i#««  NUMBER  0  TO  5  FOR  THE  PGC  SELECTED  TO  RUN  Hifil 


NAME 

SERVICE 

MAX  MSN 

PGC  NUMBER 

0  - 

DEMO  PGC  (MAM'S  SHIRT) 

ARMY 

3 

1672 

1  - 

MAM'S  COAT 

ARMY 

65 

1765 

2  - 

WOMAN'S  SHIRT 

AIR  FORCE 

21 

1671 

3  - 

WOMAN'S  SKIRT 

ARMY 

80 

1748 

4  - 

MEN'S  SHOE 

ALL 

113 

1505 

5  - 

MEN  &  WCmSN  GLOVES 

ALL 

17 

1834 

6  -  WANT  TO  ENTER  AN  ALTERNATE  PGC  NUMBER 


EXHIBIT  6-2.  QUERY  1 


The  RUN  command  (Exhibit  6-2)  initiates  the  interactive  query  session. 
Query  1  asks  the  user  to  select  the  PGC  to  be  processed.  The  query  lists  the  "demo 
PGC”  and  five  other  PGCs  that  the  user  may  choose.  The  data  for  those  PGCs  are 
already  in  the  system  and  will  be  retrieved  automatically.  If  another  PGC  is  desired, 
the  number  6  should  be  selected  and  the  query  shown  in  Exhibit  6-3  will  appear. 
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la)  ENTER  THE  PGC  NUMBER  (NOTE:  BOTH  THE  SSCFSIM. OAT/MOO  AND  THE 
MPTOll. OAT/MOO  FILES  MUST  ALREADY  HAVE  THIS  PGC'S  DATA  WITHIN 


_ J 

EXHIBIT  6-3.  QUERY  1a 


Query  la  asks  for  the  four-  or  five-digit  number  of  the  PGC  to  be  run.  Query  la 
allows  the  simulation  to  be  run  on  any  PGC  desired;  however,  the  SSCF  input  file 
prepared  by  the  capture  program  and  the  MPTOll  input  file  must  have  been 
produced  and  stored  in  the  files  named  C:\SIM\DLA\SSCFSIM.DAT  and 
C:\SIM\DLA\MPT011.DAT,  respectively.  (Separate  SSCF  and  MPTOll  input  files 
for  modified  data  also  are  made  available.  Those  files  have  a  "MOD”  extension  and 
are  discussed  in  Queries  9  and  10  of  Exhibits  6-12  and  6-13.) 


2} ENTER  0  FOR  DEMAND  (CUSTOMER  BEHAVIOR)  EQUAL  TO  MONTHLY  FORECAST 
1  FOR  VARIANCE  IN  DEMAND  BASED  ON  MAD  OF  FORECAST 
>0  FOR  DEMAND  KNOB  (e.g.,0.95  DECREASES  MEAN  DEMAND  BY  5%, 

1.05  INCREASES  THE  MEAN  DEMAND  5%  IN  RELATION  TO  FORECAST) 


EXHIBIT  6-4.  QUERY  2 
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Query  2  (Exhibit  6-4)  allows  the  user  to  control  customer  behavior  in  the 
simulation  and  isolate  its  effect  on  inventory  performance.  If  a  "0”  is  entered, 
customer  demand  is  equal  to  the  forecasted  demand  for  the  month.  If  the  user  enters 
a  *'l”,  the  demand  for  the  month  varies  about  the  monthly  forecast.  The  monthly 
demand  is  drawn  from  a  normal  distribution  with  the  forecast  as  mean  and  the  NSN- 
speciflc  MAD  as  the  standard  deviation. 

If  a  real,  positive  number  other  than  1  is  entered,  the  forecast  for  the  month  is 
multiplied  by  that  number  and  the  product  becomes  the  mean  in  the  normal 
distribution  from  which  monthly  demand  is  drawn.  Entering  a  value  of  0.95,  for 
example,  causes  monthly  demands  to  vary  about  95  percent  of  forecasted  values,  and 
the  actual  demand  for  the  entire  PGC  over  the  course  of  the  simulation  is 
approximately  95  percent  of  the  forecast.  The  demand  knob  allows  the  user,  to 
control  whether  the  simulation  overforecasts  or  underforecasts  demand  at  the  PGC 
level.  Entering  a  value  less  than  1  causes  the  simulation  to  overforecast  demand, 
while  entering  a  value  greater  than  1  causes  it  to  underforecast. 

/ - ^ 

3) ENTER  0  FOR  CONSTANT  PLT  (SUPPLIERS  BEHAVIOR)  EQUALING  THE  SSCF  PLT 

I  FOR  VARIANCE  IN  PLT  WITH  AVERAGE  BEING  2  MONTHS  LATE 
>0  FOR  PLT  SHAPE  KNOB(e.g.,  .5  DECREASES  VARIANCE  SO  AVERAGE 
IS  1  MONTH  LATE;  2  INCREASES  VARIANCE  SO  AVERAGE  IS 
APPROXIMATELY  4  MONTHS  LATE) 

7 
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EXHIBIT  6>5.  QUERY  3 

Query  3  (Exhibit  6-5)  allows  the  user  to  control  supplier  behavior  in  the 
simulation.  If  a  "0”  is  entered,  all  supplier  deliveries  arrive  exactly  as  scheduled. 
That  is,  the  simulated  PLT  will  equal  the  recorded  PLT  of  the  item.  If  a  ”1”  is 
entered,  deliveries  may  be  delayed  (i.e.,  PLTs  different  than  recorded  PLTs).  (The 
underlying  delay  distribution  also  provides  a  small  probability  that  deliveries  will 
arrive  slightly  early.)  Delays  are  based  on  an  empirical  distribution  that  causes 
deliveries  to  be  approximately  2  months  (55  days)  late  on  average.  To  increase  or 
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decrease  the  delivery  delay,  the  user  may  enter  a  positive  value  greater  than  or  less 
than  1.  For  example,  entering  a  value  of  .5  would  reduce  the  variability  in  delays  by 
50  percent  and  cause  the  average  delay  to  decrease  from  2  months  to  1  month,  and 
entering  a  value  of  2  would  increase  delay  variability  by  200  percent  and  cause  the 
average  delay  to  increase  from  2  months  to  4  months. 


EXHIBIT  6.6.  QUERY  4 


Query  4  (Exhibit  6-6)  allows  the  user  to  specify  a  long  run  for  final  results  or  a 
short  run  to  see  how  the  item  behaves.  If  a  ”0”  is  entered,  the  model  is  structured  to 
produce  final  simulation  results.  This  structuring  includes  the  removal  of  the  warm¬ 
up  period  and  the  reduction  of  trace  information  and  other  model  operations  that 
slow  processing  time.  Long  runs  should  be  used  when  the  user  is  satisfied  that  the 
model  is  configured  as  desired  and  final  numerical  results  are  to  be  produced. 

If  a  ”1”  is  entered,  the  model  is  structured  for  a  shorter  run  in  years  but  will 
produce  more  detailed  information.  For  a  short  run,  the  model  produces  detailed 
trace  information  and  dynamic  graphic  plots  of  net  stock  over  time  and  does  not 
discount  the  warm-up  period.  Short  runs  should  be  used  to  better  understand  how 
the  PGC  behaves  and  is  influenced  by  different  model  inputs. 
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5)  ENTER 
? 


SIMULATION  LENGTH  IN  YEARS 


EXHIBIT  6-7.  QUERY  5 

Query 5  (Exhibits-?)  allows  the  user  to  choose  the  number  of  years  to  be 
simulated.  The  more  years  simulated,  the  more  precise  model  results  will  be,  but 
processing  time  (actual  clock  time)  will  be  longer.  The  appropriate  number  of  years 
to  enter  depends  on  the  number  of  NSNs  in  the  PGC,  the  length  of  time  a  user  is 
prepared  to  wait  for  results,  and  the  level  of  precision  desired.  For  final  results  with 
a  long  run,  the  length  of  time  entered  should  be  from  100  to  600  years  for  most  PGCs. 
For  short  runs,  3  to  10  years  is  usually  enough  for  an  initial  look,  but  more  years 
may  be  entered  if  desired. 


6) ENTER  0  NOT  TO  ACCUMULATE  RESULTS  ACROSS  PGCs 

1  TO  DISPLAY  RESULTS  OF  SEVERAL  MODEL  RUNS  WITH  THE  SAME  PGC 
10  TO  DESTROY  EXISTING  RUMS,  &  START  RUNS  WITH  THE  SAME  PGC 

2  TO  ADD  RESULTS  OF  RUNS  OF  DIFFERENT  PGCS  TOGETHER 

20  TO  DESTROY  EXISTING  RUNS,  &  START  RUNS  WITH  DIFFERENT  PGCS 


EXHIBIT  6-8.  QUERY  6 

Query  6  (Exhibit  6-8)  allows  the  user  to  aggregate  results  across  separate  PGC 
runs.  Aggregate  statistics  are  needed  when  several  different  runs  on  the  same  PGC 
are  being  done  or  when  several  different  PGCs  are  being  processed  in  a  sequence  of 
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runs  to  determine  how  a  policy  affects  system-level  performance.  Query  6  controls 
the  format  of  the  Aggregate  PGC  Report  file.  If  a  ”0”  is  entered,  statistics  from  the 
nm  about  to  take  place  are  not  printed  to  the  Aggregate  PGC  Report  file.  To  collect 
statistics  for  multiple  model  runs  with  the  same  PGC,  a  ”10”  should  be  entered  for 
the  first  run  and  ”1”  for  all  other  runs.  To  collect  statistics  for  a  series  of  the  same 
run  on  different  PGCs,  a  ”20”  should  be  entered  for  the  first  PGC  and  a  ”2”  for  all 
other  PGCs.  Entries  of  ”10”  or  ”20”  erase  existing  information  in  the  Aggregate 
PGC  Report  file  so  that  a  new  report  can  be  produced.  The  difference  between 
entries  "1”  and  ”2”  is  that  ”2”  causes  statistics  over  different  PGCs  to  be  summed  to  a 
TOTAL  line  in  the  Aggregate  PGC  Report. 

Examples:  to  compare  three  runs  on  the  same  PGC,  one  with  a  PLT  control 
knob  value  of  .5,  one  with  the  PLT  knob  value  of  1,  and  one  with  a  PLT  knob  value  of 
1.5,  the  user  would  enter  10,  1,  and  1  in  that  order  for  the  three  model  runs.  To  see 
what  system  backorders  are  for  a  system  of  five  PGCs  running  with  VSLs,  the 
appropriate  entries  would  be  20, 2, 2, 2,  and  2  for  the  five  runs. 

f  ^ 

6a)  ENTER  5  DIGIT  RUM  ID  NUMBER 


V. 


EXHIBIT  6-9.  QUERY  6a 

Query  6a  (Exhibit  6-9)  requests  an  integer  no  larger  than  five  digits.  This 
number  identifies  the  run  when  a  series  of  runs  are  going  to  be  performed  on  the 
same  PGC.  Query  6a  is  printed  whenever  the  response  to  Query  6  is  ”1”  or  ”10.”  A 
run  ID  number  is  required  so  that  different  runs  on  the  same  PGC  'an  be 
distinguished  in  the  Aggregate  PGC  Report  file.  If  the  Query  6  response  is  ”2”  or 
”20,”  Query  6a  does  not  appear,  and  the  number  of  each  PGC  is  used  to  identify 
individual  PGC  results  in  the  Aggregate  PGC  Report. 
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C 1 ) ENTER  0 


FOR  NO  FURTHER  CHANGE  AMD  RUN 

FOR  OPTIONAL  INPUT  DATA  FILES  (QUERIES  8  TO  12) 


V _ y 

EXHIBIT 6-10.  QUERY? 

Query  7  (Exhibit  6-10)  allows  the  user  to  end  the  query  session  or  move  to  the 
additional  queries  that  involve  optional  data.  In  general,  the  first  six  queries 
provide  enough  flexibility  to  answer  a  variety  of  questions  for  which  the  optional 
queries  are  not  needed.  If  this  is  the  case,  a  "0”  is  the  appropriate  response  to 
Query  7. 

If  a  ”1”  is  entered,  several  additional  queries  are  posed.  These  queries  require 
preparation  of  data  files  prior  to  the  initial  RUN  command  at  the  beginning  of  the 
query  session.  In  particular,  to  respond  to  Query  8  on  safety  level,  the  user  must 
have  run  the  VSL  model  and  prepared  a  file  of  VSLs  (see  Appendix  D).  Queries  9, 10, 
and  11  allow  the  user  to  modify  any  of  the  inputs  in  the  SSCF,  MPTOll,  or 
Alternative  Assumption  Files,  respectively.  To  make  such  modifications,  the  user 
edits  a  special  copy  of  the  input  files  with  identical  file  names  followed  by  the 
extension  "MOD”  rather  than  "DAT”.  Queries  9,  10,  and  11  direct  the  simulation  to 
use  the  edited  "MOD”  files  as  input.  Each  time  before  editing  the  "MOD”  files,  it  is 
good  practice  to  copy  the  original  SSCF  or  MPTOl  1  files  (with  the  extension  "DAT")  to 
the  file  that  will  be  modified  (with  the  extension  "MOD").  This  action  ensures  that 
previous  modifications  in  the  "MOD”  files  are  not  accidentally  included  in  the 
cunont  run.  Commands  for  editing  and  copying  files  are  discussed  later  in  this 
chapter. 
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8) ENTER  1  FOR  VARIABLE  SAFETY  LEVEL 
0  FOR  FIXED  SAFETY  LEVEL  [D] 


EXHIBIT  6-11.  QUERY  8 

Query  8  (Exhibit -11)  allows  the  user  to  use  either  VSLs  or  the  fixed  safety 
levels  in  the  run.  If  a  ”1”  is  entered,  the  model  automatically  uses  an  optional  data 
file,  C;\SIM\DLA\VSL.DAT,  that  contains  NSN-specific  VSLs.  For  that  option,  the 
user  must  have  previously  generated  the  VSL  in  months  for  each  NSN  in  the  PGC 
and  stored  that  data  in  the  VSL  file.  The  VSL  model  automatically  produces  the 
VSL  file  (see  Appendix  D);  however,  the  user  may  enter  other  safety  levels  manually 
into  the  VSL  file  for  use  by  tiie  model. 

If  a  ”0”  is  entered  in  response  to  Query  8  (the  default  option),  the  model  uses  the 
fixed  safety  level  values  in  months  for  the  NSN  that  appear  in  the  SSCF  input  file. 


9) ENTER  1  FOR  OPTIONAL  SCF  INPUT  DATA 

0  FOR  STANDARD  SCF  INPUT  DATA  [D] 

? 


EXHIBIT  fi-12.  QUERY  9 


Query  9  (Exhibit  6-12)  allows  the  use  of  modified  SSCF  input  data.  To  modify 
the  SSCF  data,  the  user  must  edit  a  copy  of  the  SSCF  input  file  named 
C;\SIM\DLA\SSCFSIM.MOD  before  running  the  simulation.  Modifying  the  file  is 
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similar  to  editing  files  on  a  PC  with  a  word  processor  or  full-screen  editor.  Once  in 
the  editing  mode,  the  user  simply  moves  the  cursor  to  the  desired  element  in  the  file 
and  types  a  replacement  value  over  the  existing  value.  (Instructions  for  using  the 
SIMSCRIPT  editor  appear  later.)  Once  the  file  has  been  edited  and  saved,  the  user 
runs  the  model  and  enters  a  "1”  in  response  to  Query  9.  If  a  "0”  is  entered,  the 
original  (default)  SSCF  input  file  (C:'fiIM\DLA\SSCFSIM.DAT)  is  used  in  the 
simulation. 

r  ^ 

10)ENTER  1  FOR  OPTIONAL  MANAGEMENT  POLICY  TABLE  INPUT  DATA  (MPTOll) 

0  FOR  STANDARD  MANAGEMENT  POLICY  TABLE  INPUT  DATA  [D] 

? 


EXHIBIT  6-13.  QUERY  10 


Query  10  (Exhibit  6-13)  allows  the  use  of  modified  MPTOll  input  data.  To 
modify  the  MPTOll  data,  the  user  must  edit  a  copy  of  the  MPTOll  table  named 
C:\SIM\DLA\MPT011.MOD  prior  to  running  the  simulation.  The  editing  process  for 
the  MPTOll  file  is  similar  to  that  for  the  SSCF  file.  Once  the  MPTOll.MOD  file  has 
been  edited  and  saved,  the  model  can  be  run  and  a  "1”  entered  in  response  to 
Query  10.  If  a  "0”  is  entered,  the  original  (default)  MPTOll  input  file 
(C:\SIM\DLA\MPT011.DAT)  is  used  in  the  simulation. 

Query  11  (Exhibit  6-14)  allows  the  the  use  of  modified  inputs  and  assumptions 
not  contained  in  the  SSCF,  MPTOll,  or  VSL  files.  To  make  such  modifications,  it  is 
necessary  to  first  modify  the  file  C:\SIM\DLA\ASSUMP.MOD.  Once  that  file  has 
been  edited  and  saved,  the  user  can  then  run  the  model  and  enter  a  "1”  in  response  to 
Query  11.  If  a  "0”  is  entered,  the  standard  (default)  assumptions  are  used  in  the 
model  run. 

Query  11  allows  the  user  to  modify  certain  model  parameters  and  controls 
without  having  to  change  SIMSCRIPT  code  and  recompile  the  model.  The  options 
provided  by  the  Alternative  Assumption  File  in  its  current  form  are  shown  in 
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11)  ENTER 
7 


1 

0 


FOR  OPTIONAL  ASSUMPTION  FILE:  M1,M2,T,  OPTIONS,  TRACES 
FOR  STANDARD  ASSUMPTIONS  [D] 


EXHIBIT  6-14.  QUERY  11 


Exhibit  A-4  in  Appendix  A.  In  the  future,  the  Alternative  Assumption  File  could  be 
expanded  to  provide  additional  options.  Currently,  it  contains  the  Ml,  M2,  and  T 
values  that  determine  the  procurement  cycle  (see  Chapter  3),  a  trace  option  to  turn 
off  the  printing  of  SSCF  input  data  to  the  trace  output  file,  and  an  option  to  shut  off 
requisition-generating  procedures  in  the  model. 


12) ENTER  0  FOR  NO  GRAPHICS 

1  FOR  PGC  NET  STOCK  PLOT  AND  HISTOGRAM 

2  FOR  FIRST  3  NSNs  NET  STOCK  PLOT 

3  FOR  FIRST  3  NSNs  NET  STOCK  PLOT, BO  & 


ID) 

[D  -  DEMO] 

AVAILABILITY  GRAPHS 


V, 


EXHIBIT  6-1 5.  QUERY  12 


Query  12  (Exhibit  6-15)  is  used  to  control  model  output.  It  allows  the  user  to 
choose  the  type  of  graphical  presentation  the  model  will  display.  Query  12  appears 
only  if  a  "0”  has  been  entered  in  response  to  Query  4  (FOR  A  SHORT  RUN  WITH 
PLOT  &  DETAIL  TRACES). 


If  a  ”0”  is  entered  in  response  to  Query  12,  the  model  does  not  display  the 
dynamic  graphic  plots  of  net  stock.  If  a  ”1”  is  entered,  a  dynamic  plot  of  net  stock  for 
the  PGC  as  a  whole  (i.e.,  not  broken  out  by  NSN)  is  displayed.  If  a  "2”  is  entered,  a 


dynamic  plot  of  net  stock  for  each  of  the  Hrst  three  NSNs  in  the  PGC  is  displayed.  If 
a  "3”  is  entered,  the  net  stock  plot,  pie  charts  for  demand  and  backorders,  and  supply 
availability  meters  for  RTC  demand  are  displayed  for  the  first  three  NSNs  in  the 
PGC. 


=■■■“==«==  MODEL  OPTION  ASSUMPTIONS  {true*!  and  false^O) 

1) PGC  NUMBER  1672 

2) SIMULATED  DEMAND  KNOB  1.00  (0:FALSE  -  DEMAND  IS  FORECAST, else  MAO) 

3) PLT  DAYS  DELAYED  KNOB  1.00  (0:FALSE>  Constant  PLT,  else  variance) 

4) SHORT  RUN  WITH  PLOT  1  (0:FALSE>longer  run  for  definitive  results) 

5)  LENGTH  OF  SIMULATION  0  TOTAL  LENGTH  OF  RUN  WITH  WARMUP  0 

6)  0:  0  DO  NOT  ADD;  Inruns  for  same  PGC(10  =  1ST  PGC  in  group); 

2aadd  different  PGC  info  (20  >  1ST  PGC  in  group) 

8) VAR1ABLE  SAFETY  LEVEL  OPTION  0  (0:FALSE-  FIXED  SAFETY  LEVEL) 

9) EDITED  THE  SSCF  DATA  0  (0:FALSE>  use  standard  data  with  no  change) 

10) EDITEO  MPTOll  TABLE  0  (0:FALSE=>  use  Standard  data  with  no  change) 

11) EDITED  ASSUMPTIONS  0  (0:FALSE  >  standard  assumptions,  no  change) 


THIS  MODEL  RUN  WILL  TAKE  0.  HOURS  REAL  TIME  ON  ZENITH»» 
MODEL  RUN  SUBMITTED,  TO  ABORT  HIT  CTRL-C 

V. _ J 

EXHIBIT 6-16.  DISPLAY  AFTER  QUERIES 


This  concludes  the  query  session  at  the  beginning  of  a  run.  Once  the  query 
session  has  ended  and  the  model  run  has  been  submitted,  the  model  displays  the  list 
of  query  responses  entered  (Exhibit  6-16).  If  the  demonstration  PGC  or  one  of  the 
sample  PGCs  (numbers  1  through  5  in  Query  1)  is  being  run,  the  approximate  clock 
time  it  will  take  to  run  the  model  on  a  DLA  Zenith  PC  is  listed.  To  stop  a  run  for  any 
reason,  the  user  may  strike  the  ”CTRL”  and  "C”  keys,  simultaneously.  The  model 
can  also  be  stopped  during  the  query  session  in  the  same  way. 

As  the  model  runs,  data  are  automatically  printed  to  the  various  output  files 
and  if  requested,  plots  are  automatically  displayed  on  the  screen.  Once  finished, 
each  plot  remains  on  the  screen  until  the  user  types  an  integer  and  a  return,  [R]. 
Printed  tables  also  remain  on  the  screen  until  the  model  is  finished  running.  For 
tables,  a  "?”  appears  at  the  bottom  of  the  screen  when  the  model  is  finished 
processing.  Again,  type  an  integer  and  a  [R]  to  advance  to  the  next  screen.  To  replay 


any  past  screens  one  at  a  time,  press  the  ”F8”  key  and  the  model  will  retrieve  and 
display  previous  screens. 


To  make  a  hard  copy  of  any  graphic  display,  press  the  ”AIjT”  and  'Tl”  keys 
simultaneously.  A  hard  copy  of  the  graphics  can  only  be  made  while  the  graphic  is 
on  the  screen  and  before  exiting  from  the  run.  To  make  a  hard  copy  of  a  table,  press 
the  ’’Shift”  and  ’TrtSC”  keys  simultaneously. 


TO  EXIT  MODEL  RUN,  ENTER  A  INTEGER  AND  [R] 
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EXHIBIT  6-17.  EXITING  A  RUN 

To  exit  the  model  (Exhibit  6-17)  and  return  to  SIMLAB,  enter  an  integer  and 
[R].  SIMSCRIPT  automatically  erases  all  the  graphic  displays  and  tables.  From 
SIMLAB,  it  is  possible  to  view,  edit,  print,  or  copy  the  output  from  the  run,  as 
discussed  next. 

DATA  FILES  AND  FLOWS 

This  section  summarizes  how  all  the  components  of  the  C&T  simulation 
system  —  the  C&T  simulation,  the  capture  program,  the  VSL  model,  and  the  various 
input  files  and  output  files  in  the  system  —  are  linked  together. 

Figure  6-1  illustrates  the  basic  data  flows  in  the  system.  The  hub  of  the  system 
is  the  C&T  simulation  itself.  The  simulation  accepts  four  types  of  input  files.  The 
two  required  files  are  the  SSCF  input  file  and  the  MPTOll  file.  The  ’’MOD”  versions 
of  the  SSCF  and  MPTOll  files  are  used  if  modified  data  are  desired;  otherwise,  the 
’DAT”  files  with  original  input  data  are  uc'‘d.  Both  inputs  are  downloaded  from  the 
SAMMS  data  base.  The  SSCF  file  is  first  preprocessed  by  the  SIMSCRIPT  capture 
program  (see  Appendix  C).  \Noie:  The  SSCF  input  data  for  the  demonstration  PGC 
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(#0  in  Query  1)  is  stored  in  separate  files*  DEMOPGC.DAT  and  DEMOPGC.MOD,  to 
avoid  the  use  of  regular  input  files  in  demonstration  and  practice  with  the  model.] 


>  These  Input  files  to  the  simulation  are  also  used  by  the  VSL  model. 


FIG.  6-1 .  DATA  PILES  AND  FLOWS 

The  remaining  two  inputs  accepted  by  the  simulation  are  two  optional  data 
files:  the  Optional  Assumption  file  (see  Query  11)  and  the  VSL  file  (see  Query  8). 
The  VSL  model  generates  the  VSL  file  using  the  same  input  files  as  the  simulation. 

The  C&T  simulation  generates  two  basic  output  files:  the  Aggregate  PGC 
Report  (see  Query  6)  and  the  Detail  Trace  Output  Report  (see  Chapter  4). 

FILE  MANIPULATION 

This  section  describes  the  SIMSCRIPT  commands  that  allow  a  user  to  view, 
edit,  print,  or  copy  files.  SIMSCRIPT  contains  an  editor  that  can  perform  most 
standard  editor  functions.  Any  file  can  be  brought  into  the  editor  where  the  user  can 
page  through  it  for  viewing,  searching  for  a  string,  inserting  text,  and  moving  blocks 
of  information.! 


I A  full  description  of  the  SIMSCRIPT  editor  appears  in  Chapter  5  of  the  PC  SIMSCRIPT  II.5 
Introduction  and  User’s  Manual,  Third  Edition,  published  by  CACI,  Inc.,  Jul  1987. 
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Viewing  or  Editing  a  File 

To  view  and  edit  a  file,  that  file  must  be  brought  into  the  SIMSCRIPT  editor. 
For  example,  to  modify  the  SSCF  input  data,  the  user  would  type  the  command 
shown  in  Exhibit  6-18. 

C SINLAB>ED1T/DATA  SSCFSIM.MOD  [R]  ^ 
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EXHIBIT 6-18.  ENTERING  THE  EDITOR 

After  the  above  command  has  been  entered,  the  top  of  the  SSCF  input  file  is 
displayed  on  the  screen.  The  user  can  then  move  the  cursor  (using  the  number  pad 
keys)  to  the  data  element  to  be  modified  and,  making  sure  the  insert  mode  is  off 
(press  the  ”Ins”  key  if  it  is  not),  enter  the  new  data.  New  data  elements  do  not  have 
to  be  placed  in  exactly  the  same  position  as  old  data  elements  as  long  a  space  is  left 
between  adjoining  data  elements. 

( - ^ 

Esc 

SIMEDIT>EXIT  [Rl 
SimLab> 


V _ J 

EXHIBIT  6-19.  EXITING  THE  EDITOR 
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Once  a  file  has  been  edited  as  desired,  press  the  ’^sc”  key  (Exhibit  6-19).  The 
"EXTr”  command  saves  the  modified  file  and  exits  the  editor.  A  "QUIT”  command 
exits  the  editor  without  saving  the  modified  file.  Besides  modifying  the  file,  the 
editor  can  be  used  to  view  output  as  well. 

Printing  a  File 

Hard  copies  can  be  printed  after  viewing  the  simulation  output  files.  To  print  a 
hard  copy  of  the  Detail  Trace  Output  Report,  enter  the  command  in  Exhibit  6-20. 

C SiniLab>PRIHT/DATA  DLAOUT.DAT  [Rl  ^ 
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EXHIBIT  6-20.  PRINTING  A  FILE 

By  replacing  DLA.OUT.DAT  with  the  name  of  any  other  input  or  output  file,  it 
is  possible  to  print  a  hard  copy  of  that  file  too.  No  file  path  is  required  to  print  the 
simulation  input  or  output  files. 

Copying  a  File 

SIMSCRIPT  allows  you  to  make  copies  of  any  of  the  files  used.  For  example, 
you  wish  to  copy  the  trace  results  to  an  alternate  file  (because  the  model  rewrites  the 
trace  file  each  time  it  is  run).  To  perform  the  "copy”  command  and  any  other  Disk 
Operating  System  (DOS)  commands  while  in  SIMSCRIPT,  t3rpe  the  desired  DOS 
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command  preceded  by  a  For  example,  the  command  string  in  Exhibit  6-21 
copies  the  trace  file  to  a  file  called  SCENARIO.  1: 


(^imLab>&COPY  C:\S1M\PLA\DLA0UT.DAT  C;\S1M\DLA\SCEMARI0.  1 


EXHIBIT  6-21.  COPYING  A  FILE 


Correcting  a  Run  Time  Error 

When  running  the  model,  a  "run  time”  error  may  occur.  This  will  happen,  for 
example,  if  a  character  is  entered  when  a  number  is  called  for.  In  that  case,  the 
debug  window  will  open  on  the  monitor  screen  and  SIMSCRIPT  will  write  an  error 
message.  To  exit  debug  and  rerun  the  model,  type  the  commands  in  Exhibit  6-22. 

/  N 

Debuq>QmT  fRi 


EXHIBIT  6-22.  CORRECTING  A  RUN  TIME  ERROR 
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Ending  a  SIMSCRtPT  Session 


To  end  a  SIMSCRIPT  session  and  return  to  DOS,  enter  "QUIT”  from  the 
Simlab  line  (see  Exhibit  6-23). 


/ - 

SimLab>QUIT  fRl 
C:\SIM> 


V 


EXHIBIT  6<23.  ENDING  A  SIMSCRIPT  SESSION 
Figure  6-2  summarizes  all  the  SimLab  commands  discussed  in  this  chapter. 
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•  TO  LOG  ONTO  SIMSCRIPT 


>  C:>CD\SIM  fRi 

>  C:  \  SIM  >Simlab  [R] 

>  SimLab>SELECTDLA  [R] 

>  SimLab> 

•  TO  RUN  THE  PROGRAM 

>  SimLab>RUN  [R] 

>  0  [R]  (numeric  zero)  (moves  to  next  graphic  screen) 

>  F8  (flips  between  screens) 

•  VIEWING  OR  EDITING  A  FILE  (Example  file;  DEMOPGC.MOO) 

>  To  enter,  type: 

SimLab>EDIT/DATA  DEMOPGCMOD  [R) 

>  To  perform  edits  or  scrolling  (see  Chapter  5,  K  SIMSCRIPT  11.5) 

*  To  exit,  type: 

-  Hit  ESC  key 

-  SIMEDIT>E)^  [Rl  (saves edits) 

-  SIMEDIT>QUIT  (Rl  (exits  without  save) 

•  TO  PRINT  A  FILE 

SimLab>PRINT/DATA  DEMOPGCMOD  [R] 

(Note:  To  print  graphics,  press  ALT  and  FI  keys) 

•  IN  CASE  OF  ERROR  CONDITIONS 

»  Write  down  error  message,  if  past  query  selection 

>  [R]  (hit  return  to  get  to  debug  line) 

»  Debug >QU IT  [R]  (to  try  again;  e.g.,  if  the  error  is  the  result 

of  a  typo  made  while  entering  at  keyboard) 

•  TO  END  SESSION 

SimLab>QUIT 

•  TO  COPY  AND  SAVE  SIMULATION  RESULT  IN  A  SEPARATE  FILE 
(e.g.,  named  "Policy  1 ")  TYPE: 

SimLab>& Copy C:\SIM\DLA\DLAOUT.DAT  C:\SIM\DLA\POLICY1  [R] 

Mot0:  [R]  »  strike  return  key;  underlining  denotes  what  you  enter. 

FIG.  6<2.  COMMAND  SUMMARY 


(change  to  SIM  directory  from  root) 
(gets  to  SIMSCRIPT) 

(change  to  C&T  model's  directory) 
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TRANSFERRING  FILES  TO  LOTUS  1-2-3 

This  section  describes  how  to  transfer  all  or  parts  of  input  and  output  files  into 
LOTUS  1-2-3.  LOTUS  1-2-3  allows  the  user  to  plot  values,  calculate  additional 
statistics,  and  perform  other  analyses  on  input  or  output  data.  The  example  in 
Exhibit  6-24  illustrates  how  to  transfer  the  Detail  Trace  Output  Report  to 
LOTUS  1-2-3. 

C SiiiiLab>&COPY  C; \S1M\DLA\DLA0UT.DAT  C;\L0TUS\TRAMSFER.PRH  fRI 


V _ y 

EXHIB(T6-24.  COPYJNG  TO  A  LOTUS  1-2-3  FILE 

As  described  earlier,  the  copy  command  simply  makes  a  copy  of  the  trace 
results  and  stores  them  in  the  LOTUS  directory  under  the  name  of 
”TRANSFER.PRN”.  The  target  file  may  be  assigned  any  name  but  does  require  the 
'TRN”  extension. 


Si]nLab>EDlT/DATA  C;\L0TUS\TRAHSFER.PRM  fRl 


EXHIBIT6-25.  EDITING  PRIOR  TO  LOTUS  1-2-3  OPERATIONS 
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The  rnmmand  in  Exhibit  6-25  calls  the  just-created  copy  of  the  trace  report  into 
the  SIMSCRIPT  editor.  The  next  step  is  to  delete  all  extraneous  data  and  leave  only 
the  data  to  be  manipulated  in  LOTUS  1-2-3.  To  delete  a  character,  strike  the  'DEL” 
key.  To  delete  lines,  strike  the  "CTRL”  and  "Y”  keys,  simultaneously.  To  delete 
blocks  of  information,  mark  the  beginning  of  the  block  (t3T)e  "CTRL”  and  "K”,  then 
"B”)  and  mark  the  end  of  the  block  (tsrpe  "CTRL”  and  "K”,  then  "K”)  and  then  delete 
the  block  (type  "CTRL”  and  "K”,  then  "Y”). 

Once  extraneous  information  has  been  deleted,  all  text  headings  or  titles 
should  be  placed  between  quotes  ("TITLE”).  Once  all  editing  is  finished,  the  user 
should  save  and  exit  the  document  ("Esc”  followed  by  "EXIT”).  Finally,  "QUIT” 
SimLab. 

The  "PRN”  file  just  created  can  now  be  directly  read  by  LOTUS  1-2-3.  The  user 
simply  calls  the  LOTUS  1-2-3  program,  selects  the  "File”  command,  then  the 
"Import”  command,  the  "Number”  command,  and  finally  selects  the  "TRANSFER” 
file.  The  selected  data  will  appear  in  the  spreadsheet. 
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CHAPTER  7 


OBSERVATIONS  AND  SUGGESTIONS 


Among  the  different  issues  considered  in  developing  the  C&T  simulation,  three 
require  further  comment:  the  implementation  of  matrix  deliveries,  the  estimation  of 
demand  and  leadtime  variability,  and  the  forecasting  of  demand.  In  the  course  of 
model  development,  we  recognized  that  these  issues  are  particularly  important  in 
how  they  influence  the  simulation  and  how  they  influence  C&T  operations 
themselves.  This  chapter  offers  some  observations  and  suggestions  on  those  issues 
and  presents  some  ideas  for  future  enhancements  to  the  simulation. 

MATRIX  DELIVERIES 

Among  the  four  delivery  methods  developed  for  C&T  items.  Method  of 
Delivery  1  is  specifically  designed  to  avoid  incremental  deliveries.  Under  Method  1, 
full  order  quantities  for  each  NSN  in  the  PGC  —  whether  the  NSN  is  an  X,  Y,  or  Z 
item  -  are  scheduled  to  be  delivered  at  a  single  time  in  the  PGC’s  delivery  period. 
Method  1  is  the  preferred  method  of  delivery  when,  for  whatever  reason,  the  supplier 
is  better  able  to  deliver  whole  orders  for  a  given  NSN  at  one  time  rather  than 
spreading  deliveries  out  over  several  months.  The  question  is  with  the  way  that 
leadtimes  are  being  defined  for  items  under  Method  1. 

As  described  in  the  DLA  documentation  available  on  matrix  deliveries 
[DLAM  4140.2,  Chapter  26,  Delivery  Schedules  (Working  Copy)],  some  Method  1 
items  classified  as  ”X”  or  will  be  assigned  reorder  point  leadtime  values  that  do 
not  correspond  with  the  scheduled  delivery  month  for  the  item.  Figure  7-1,  which  is 
extracted  from  DLAM  4140.2,  Chapter  26,  provides  qn  example. 

Following  the  leadtime-setting  rules  spelled  out  in  Chapter  26,  the  leadtime  for 
all  ’’X”  items  is  set  to  be  the  time  to  first  delivery  plus  2  months.  As  indicated  by  the 
circled  entries  in  Figure  7-1,  this  results  in  the  last  two  ”X”  items  being  assigned  a 
reorder  point  leadtime  that  is  1  month  shorter  than  it  should  be.  That  is,  if  the 
manufacturer  delivers  those  ”X”  items  exactly  on  schedule,  they  will  arrive  1  month 
later  than  their  leadtime  says  they  will  arrive.  This  amounts  to  "planning”  to  cut 
into  safety  levels  for  those  items  and  increasing  the  risk  of  backorders.  (Stochastic 
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Source;  OLAM  4140.2.  Chapter  26,  Delivery  Schedules  QNorking  Copy). 

FIG.  7-1.  METHOD  1  DEUVERY  SCHEDULE  EXAMPLE 

effects  will  cause  variability  in  the  occurrence  of  backorders  from  one  instance  to  the 
next,  and  safety  levels  will  often  cover  late  deliveries,  but  even  with  these 
qualifications,  the  leadtime-setting  policy  as  described  will  cause  expected  backorder 
levels  to  be  greater  than  they  would  be  otherwise.)  The  same  problem  exists  for  the 
three  circled  ”Y”  items. 

To  avoid  the  problem  of  late  deliveries,  a  needs- test  has  been  included  in  C&T 
matrix  delivery  planning.  The  purpose  of  the  needs  test  is  to  detect  any  incursions 
into  safety  level  caused  by  the  delivery  schedule  and  rearrange  the  schedule  to  avoid 
them.  The  problem  is  that  this  rearrangement  usually  forces  the  reintroduction  of 
incremental  deliveries,  thus  defeating  the  original  purpose  of  the  Method  1 
approach.  When  rearrangements  are  attempted,  month-by-month  delivery 
capacities  specified  in  the  schedule  usually  force  early  deliveries  to  be  spread  out  in 
order  to  make  room  for  the  deliveries  that  have  to  be  moved  up.  (Figure  7-1  can  be 
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used  to  see  how  this  happens.  To  move  the  delivery  of  the  third  X  item  up,  it  is 
necessary  to  split  the  delivery  of  the  second  X  item  because  the  delivery  capacity  in 
the  third  month  is  20  percent.) 

To  avoid  this  problem  for  Method  1,  an  alternative  approach  would  be  to  set  the 
leadtime  for  each  NSN  based  on  the  NSN’s  scheduled  delivery  month.  This  approach 
would  be  consistent  with  the  Method  1  goal  of  avoiding  incremental  deliveries.  It 
would  also  reduce  the  number  of  times  the  needs  test  forces  a  change  in  the  delivery 
schedule.  The  leadtime-setting  rules  in  the  new  DLAM  4140.2,  Chapter  26,  Delivery 
Schedules  appear  to  be  designed  for  incremental  deliveries.  They  set  leadtimes  at 
reasonable  points  in  the  midst  of  a  sequence  of  partial  deliveries.  When  the  full 
order  is  delivered  at  one  time,  however,  it  makes  sense  to  simply  set  the  leadtime 
based  on  the  scheduled  delivery  month. 

The  second  observation  about  matrix  deliveries  concerns  the  leadtime-setting 
rules  themselves  as  defined  in  the  new  Delivery  Schedules  chapter.  The  rules  work 
well  if  the  delivery  period  is  6  months  long  (i.e.,  has  six  delivery  increments).  They 
do  not  work  as  well  if  the  number  of  delivery  increments  is  not  six.  Suppose,  for 
example,  the  number  of  delivery  increments  is  12,  corresponding  to  a  12-month 
delivery  period.  Under  the  rules  for  Method  4,  Z  items  are  assigned  a  leadtime 
corresponding  to  the  first  delivery  time  plus  five-sixths  of  the  number  of  delivery 
increments.  On  a  12-month  schedule,  that  rule  schedules  Z  items  for  delivery  at  the 
end  of  the  eleventh  month.  [First  delivery  at  the  end  of  month: 
1  -H  (5/6  X  12)  =  1  -H  10  =  11.]  This  does  not  correspond  with  the  plan  to  schedule 
Z  items  for  delivery  in  the  final  month  of  the  delivery  period,  as  called  for  under 
Methods  1,  2,  and  4.  In  some  cases,  therefore,  the  leadtime-setting  rules,  in  effect, 
cause  an  extra  month’s  worth  of  stock  to  be  carried  —  above  and  beyond  the  sxim  of 
leadtime  demand  and  safety  level. 

A  Hnal  observation  about  matrix  deliveries -has  to  do  with  the  needs  test. 
Under  DLA’s  implementation  plan,  the  delivery  schedule  for  a  given  order  of  a 
multi-item  PGC  is  based  on  the  relative  mix  of  actual  order  quantities  among  the 
different  NSNs  being  ordered.  Because  of  the  way  PGCs  are  reordered,  the  actual 
order  quantity  for  a  given  item  will  often  be  different  (smaller)  than  its  full  order 
quantity.  (Only  when  items  are  at  their  reorder  points  is  a  full  order  quantity 
ordered;  when  items  are  not  at  their  reorder  point,  they  are  ordered  only  up  to  their 
acquisition  objective.)  This  means  that  items  classified  as  X,  Y,  or  Z  based  on  the 
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relative  size  of  their  full  order  quantity  may  change  class  when  an  actual  order  is 
placed.  Large  order  quantity  (X)  items  may  account  for  only  a  small  part  of  a  given 
order  (and  therefore  become  Z  items  in  the  delivery  schedule),  while  Z  items  may  be 
the  bf  j;gest  in  the  order  (and  therefore  become  X  items). 

This  migration  of  items  from  one  delivery  category  to  another  causes  planned 
leadtimes  in  the  delivery  schedules  to  differ  from  leadtimes  used  in  setting  reorder 
points.  1  Not  surprisingly,  when  the  needs  test  is  applied  to  solve  the  migration 
problem,  it  tends  to  move  problem  items  back  towards  delivery  points  that 
correspond  to  reorder  point  leadtimes  (while  at  the  same  time,  as  noted  earlier, 
forcing  other,  nonproblem  items  into  incremental  delivery  patterns). 

Rather  than  uncoupling  reorder  point  leadtimes  from  delivery  schedule 
leadtimes  and  appl3ring  a  needs  test,  an  alternative  approach  would  be  to  always  use 
the  same  matrix  delivery  schedule  for  a  PGC  based  on  its  full  order  quantities. 
X  items  would  always  be  X  items,  Y  items  would  always  be  Y  items,  and  Z  items 
would  always  be  Z  items.  This  alternative  would,  in  effect,  couple  reorder  point 
leadtimes  with  delivery  leadtimes  and  remove  the  need  for  a  needs  test. 

What  DLA  gives  up  if  it  adopts  this  "coupled”  approach  is  that  occasionally  (no 
more  than  20  percent  of  the  time  based  on  preliminary  experiments  with  the 
simulation)  the  smaller  order  quantities  in  an  order  may  be  scheduled  for  early 
delivery  and  the  larger  quantities  for  later  delivery.  This  scheduling  could 
theoretically  inconvenience  suppliers.  When  this  happens,  however,  the  small 
orders  being  requested  for  early  delivery  will  be  for  the  commonly  requested  sizes. 
Furthermore,  it  is  not  clear  that  such  requests  will  be  that  inconvenient  for  the 
suppliers.  The  question  is  whether  supplier  delivery  preferences  are  based  on  the 
sizes  of  orders  or  on  the  sizes  ordered.  Suppliers  may  be  quite  capable  of  (and  might 
even  prefer)  making  early  deliveries  of  small  orders  for  commonly  requested  sizes 
and  later  deliveries  of  larger  orders  for  uncommon  sizes. 

Finally,  a  general  concern  is  one  of  principle.  DLA  should  set  a  limit  on  its 
willingness  to  "plan”  incursions  into  safety  level  or  backorders  to  accommodate 
suppliers.  The  fundamental  reason  for  developing  schedules  convenient  for 


^We  believe  the  needs  test  was  developed  to  solve  the  migration  problem.  Sensing  that 
delivery  schedules  based  on  relative  order  size  might  cause  some  items  to  be  delivered  too  late, 
developers  of  matrix  deliveries  included  the  needs  test  to  avoid  this  happening. 
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suppliers  was  that  such  action  would  reduce  leadtime  variability,  and  that  would 
reduce  backorders.  The  needs  test  cannot,  in  every  case,  eliminate  all  schedule- 
induced  ’^planned’*  backorders.  By  building  delivery  schedules  based  on  reorder 
point  leadtimes,  schedule-induced  backorders  can  be  avoided  altogether,  by  taking 
advantage  of  how  reorder  point  systems  work.  If  other  backorders  are  induced  under 
the  coupled  approach  because  of  supplier  difficulties  with  delivery  schedules,  it  is  not 
clear  that  any  more  backorders  are  generated  than  the  number  of  backorders  left 
unresolved  by  the  needs  test. 

ESTIMATION  OF  DEMAND  AND  LEADTIME  VARIABILITY 

"Variability  of  demand"  refers  to  the  natural  variation  in  demand  from  one 
period  (month  or  quarter)  to  the  next  that  takes  place  about  the  underl5ring  average 
demand  rate.  With  an  average  demand  rate  of  100  units  per  quarter,  for  example,  a 
given  quarter  will  usually  experience  something  other  than  exactly  100  demands; 
however,  from  one  quarter  to  the  next,  demands  will  distribute  themselves  about  the 
100-per-quarter  average.  Information  about  the  variability  of  demand  is  carried  by 
the  MAD  data  element  in  SAMMS. 

As  discussed  in  Chapter  3  (see  Equations  3-8  and  3-9)  and  in  Chapter  5,  the 
MAD  value  for  each  NSN  is  a  smoothed  measure  of  forecast  error.  That  is,  MAD  is 
computed  as  a  weighted  average  of  the  difference  between  actual  and  forecasted 
demand  in  the  period  just  ended  (either  month  or  quarter)  and  the  previous  period’s 
MAD,  using  an  "alpha  factor”  as  a  weighting  factor.  The  alpha  factor  smooths  the 
estimate  by  combining  the  forecast  error  made  in  the  period  just  ended  with  the 
forecast  errors  of  previous  periods,  recursively  embedded  in  the  MAD  term. 

The  concern  is  that  for  C&T  POI  items,  current  rules  for  calculating  MAD  may 
prevent  it  from  giving  as  accurate  an  estimate  of  demand  variability  as  it  could.  The 
suggestion  is  that  DLA  should  consider  using  con'eclive  alpha  factors  in  calculating 
MAD  for  POI  items  when  POI  forecasts  have  been  increasing  or  decreasing  over 
time. 


It  is  important  to  calculate  MAD  properly.  As  discussed  in  Chapter  5,  MAD 
plays  a  key  role  in  the  generation  of  customer  demand  and  signiHcantly  influences 
whether  the  simulation  is  able  to  produce  realistic  results.  If,  as  suggested  in 
Chapters,  MAD  fails  to  reflect  real-world  demand  variability  as  accurately  as  it 
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could  (because  too  much  weight  is  being  put  on  "old”  forecast  errors),  the  simulation 
is  not  as  realistic  as  it  could  be. 

Improving  the  accuracy  of  the  simulation  is  not  the  only  reason  to  change  the 
way  MAD  is  calculated  for  POI  items.  The  more  important  reason  is  that  MAD  will 
become  very  important  in  determining  C&T  stockage  requirements  if  and  when  the 
C&T  Directorate  adopts  variable  safety  levels.  In  the  past,  with  fixed  safety  levels 
based  on  months  of  demand,  demand  variability  (as  measured  by  MAD)  has  had  no 
role  in  the  setting  of  C&T  safety  levels.  It  will  have  such  a  role  if  the  C&T 
Directorate  adopts  VSLs;  it  serves  as  the  basis  for  estimating  the  standard  deviation 
in  leadtime  demand,  which  is  a  key  parameter  in  VSL  formulas.  (Appendix  D 
presents  a  complete  discussion  of  how  VSLs  are  computed.) 

Separate  from  demand  variability  is  the  question  of  leadtime  variability. 
Leadtime  variability  refers  to  the  natural  tendency  of  actual  leadtimes  to  vary 
around  the  estimated  leadtime,  which  again  is  an  average.  Like  demand  variability, 
leadtime  variability  influences  both  simulation  performance  and  real-world  C&T 
performance.  For  the  simulation,  we  have  used  6  months  of  C&T  Contract  Line  Item 
Number  (CUN)  Delinquency  Report  data  to  build  a  probability  distribution  for  the 
nximber  of  days  late  or  early  that  C&T  suppliers  deliver  replenishment  orders.  We 
could,  with  additional  programming,  replace  that  method  with  NSN-specific 
leadtime  variability  distributions  if  the  right  data  were  available. 

At  C&T  operations,  variability  in  leadtime  demand  is  as  much  a  result  of 
leadtime  variability  as  demand  variability.  And  yet,  leadtime-demand  variability  is 
calculated  using  only  demand  variability  (as  measured  by  MAD)  and  the  (average) 
leadtime.  No  consideration  is  made  of  leadtime  variability.  [For  details,  see  the 
discussion  of  mean  absolute  deviation  in  leadtime  (MADLT)  demand  in  Appendix  D.] 

We  suggest  that  DLA  consider  collecting  data  specifically  aimed  at  getting  a 
better  view  of  leadtime  variability  at  the  NSN  level.  Those  data  not  only  would 
make  it  possible  to  improve  simulation  realism  but  would  be  useful  in  efforts  to 
improve  C&T  operations.  Without  good  information  on  leadtime  variability  at  the 
NSN  level,  for  example,  we  will  be  unable  to  determine  whether  the  new  matrix 
delivery  policies  are  having  the  desired  effect  on  individual  PGCs.  (While  the  CLIN 
Delinquency  reports  give  good  system- wide  indications,  they  do  not  show  results  by 
PGC.  The  data  to  be  collected  under  the  new  matrix  delivery  procedures  is  not 
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focused  on  leadtime  variabilities  but  rather  on  how  often  schedules  have  to  be 
changed  with  the  needs  test.) 

If  and  when  the  C&T  Directorate  adopts  VSLs,  leadtime  variability  data  will 
be  required  if  it  is  decided  that  new  safety  levels  must  consider  leadtime  variability 
as  well  as  demand  variability.  Although  the  consideration  of  leadtime  variability 
would  put  the  C&T  Directorate  ahead  of  other  DLA  Inventory  Control  Points,  it  may 
be  both  necessary  and  appropriate  for  the  C&T  Directorate  to  take  that  lead,  given 
the  nature  of  C&T  suppliers  and  leadtimes.  The  mathematics  for  incorporating 
leadtime  variability  into  C&T  safety  levels  is  not  a  serious  technical  problem. 
(Formulas  for  including  leadtime  variability  in  the  calculation  of  standard  deviation 
in  leadtime  demand  are  available  in  the  current  literature.) 

DEMAND  FORECASTING 

Throughout  development  of  the  C&T  simulation,  DLA  personnel  at  both 
Headquarters  and  the  C&T  Directorate  have  raised  the  question  of  improving  C&T 
demand  forecasting.  The  simulation  uses  Supply  Control  File  data  reflecting  POI 
and  QFD  forecasts  to  generate  new  forecasts  over  time  and  to  generate  demands  over 
time.  The  simulation  does  not  and  cannot  make  C&T  demand  forecasts  any  better 
than  they  are  today. 

As  fallout  from  the  validation  work  described  in  Chapter  5,  however,  we  can 
suggest  a  possible  approach  to  the  forecasting  problem.  As  part  of  the  validation 
effort.  Flash  Reports  from  1986  and  1988  were  checked  for  correlations  in  the  data. 
Any  pattern  that  held  in  the  Flash  Reports  over  time  was  a  possible  candidate  for 
comparison  with  model  results  for  validation.  The  only  category  of  Flash  Report 
data  that  showed  reasonably  high  correlation  at  the  NSN  level  (PGC-level 
correlations  were  more  common)  was  the  ratio  of  average  monthly  forecast  to 
average  monthly  actual  demand.  In  particular,  biases  in  NSN  forecasts  in  1986 
(reflected  in  forecast-to-actual  ratios)  usually  existed  in  1988  in  the  same  direction 
and  to  roughly  the  same  degree. 

These  observations  apply  only  to  two  PGCs,  which  account  for  about  85  NSNs. 
We  cannot  conclude,  therefore,  that  forecast  biases  are  stable  over  time  for  all  C&T 
items.  The  fact  that  the  biases  did  hold  for  our  sample,  however,  suggests  that 
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possibility.  If  the  stable  biases  do  exist,  that  Information  could  be  used  to  improve 
the  demand  forecasting  process  at  the  NSN  level. 

To  test  whether  NSN-level  demand  forecasting  bias  exists,  we  suggest  that 
DLA  undertake  a  program  to  accumulate  forecast  and  actual  demand  data  from 
Flash  Reports  over  time.  With  easy  access  to  historical  Flash  Report  data,  it  might 
be  possible  to  improve  the  accuracy  forecasts.  The  simulation  could  also  take  NSN- 
level  demand  bias  information  into  account  in  its  demand-generating  processes. 

FUTURE  IDEAS  AND  DIRECTIONS 

Like  any  model,  the  C&T  simulation  has  areas  in  which  enhancements  and 
improvements  can  be  made.  With  some  additional  programming,  the  following 
options  and  features  could  be  added. 

A  ”short-run-with-replications”  version  of  the  model  could  be  developed  for 
analyzing  trends  in  demand  forecasts  and  other  transient  effects.  Before  taking  this 
step,  however,  we  recommend  that  DLA  consider  historical  data  analysis  as  an 
alternative  approach  to  the  problem. 

An  automated  batch-processing  capability  allowing  the  model  to  process 
collections  of  PGCs  automatically,  without  separate  user  inputs  for  each  PGC,  could 
be  developed.  That  development  would  involve  the  creation  of  a  batch  file  containing 
the  desired  inputs  and  switch  settings  to  be  applied  to  every  PGC  in  the  collection. 
We  suggest  that  DLA  not  develop  this  feature  until  it  decides  whether  it  has  to 
process  every  PGC  in  the  C&T  system  in  a  single  run  or  whether  particular 
subcollections  are  desirable  for  different  applications.  Perhaps  by  using  several  PCs, 
each  processing  a  different  collection,  DLA  can  get  more  flexibility  than  would  be 
available  with  a  single,  total-system  batch-processing  capability  on  one  machine. 

In  any  simulation,  a  tradeoff  must  be  made  between  the  level  of  detail 
incorporated  and  the  processing  time  required  for  a  run.  The  more  activities  that  are 
simulated,  the  longer  the  run.  For  example,  the  creation  and  tracking  of  requisition 
demands  increases  run  time  by  about  30  percent.  When  total  unit  demand  and 
overall,  unit- level  supply  performance  are  the  only  measures  of  interest,  requisition 
processing  is  not  needed.  An  alternative  approach  to  the  problem  of  running  time  is 
to  use  the  simulation  to  help  develop  and  test  analytic  techniques  for  approximating 
C&T  system  effects.  Analytic  models  run  considerably  faster  than  simulations,  and 
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an  approximate  analytic  model  for  C&T  inventory  management  is  worth  pursuing. 
Such  a  model  would  not  attempt  to  incorporate  the  exact  mathematics  to  handle 
multi-item  PGCs  correctly  for  every  item.  Instead,  it  would  produce  approximations 
whose  reasonableness  could  be  tested  and  verified  with  the  simulation. 

Finally,  models  are  limited  by  their  data.  The  better  the  data,  the  better  the 
model.  More  time  must  be  spent  comparing  real-world  results  with  model  results  to 
validate  and  improve  the  model.  The  possibility  of  incorporating  historical  Flash 
Report  data  to  make  adjustments  to  NSN-level  demand  forecasts,  discussed  earlier, 
is  an  example.  Such  an  effort,  however,  should  be  accompanied  by  an  effort  to  collect 
more  information  over  longer  periods  of  time  and  in  more  usable  form.  At  present, 
backorder  information  is  only  available  at  the  requisition  level  and  represents 
snapshots  taken  at  the  end  of  each  month,  without  the  accumulation  of  quarterly  or 
annual  statistics.  The  asset  information  in  Flash  Reports  and  the  backorder  data  in 
Never-Out  Item  Reports  should  be  combined  and  made  accessible  in  PC-readable 
form  without  having  to  manually  enter  data  from  hard-copy  reports. 

As  DLA  Headquarters  and  the  C&T  Directorate  use  the  C&T  simulation,  other 
desirable  features  will  become  apparent.  The  C&T  simulation  will  also  evolve  as  it 
is  incorporated  into  larger  scale  simulation  of  inventory  management  across  DLA. 
In  this  context,  the  C&T  simulation  represents  a  first  step  towards  developing  a 
general-purpose  simulation  system  at  DLA  that  can  reflect  unique  operating 
practices  at  each  DLA  Supply  center. 
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APPENDIX  A 


INPUT  DATA 

The  five  exhibits  in  this  appendix  are,  respectively,  a  Standard  Automated 
Materiel  Management  System  (SAMMS)  Special  Supply  Control  File  (SSCF)  report 
for  one  national  stock  number  (NSN)  (one  size  of  a  woman’s  shirt);  the  input  file  for  a 
three-item  Procurement  Grouping  Code  (PGC)  (man’s  shirt  —  three  sizes  shown) 
prepared  by  the  capture  program  from  the  SSCF  reports  for  the  three  NSNs;  a 
Management  Policy  Table  11  (MPTOll)  (formatted  with  new  matrix  delivery 
schedule  information  and  with  NSN  list  suppressed);  an  Alternative  Assumption 
File;  and  the  distribution  for  determination  of  requisition  sizes. 

Together  the  SSCF  input  file  for  the  set  of  NSNs  in  a  PGC  and  the  MPTOll  for 
the  PGC  contain  the  required  input  data  for  a  simulation  run  on  a  PGC.  Other  input 
information  is  either  control  information  entered  in  response  to  queries  or  optional 
information  that  can  be,  but  does  not  have  to  be,  supplied  prior  to  a  run.  Both  SSCF 
and  MPTOll  files  can  be  modified  to  contain  alternative  values  through  the  use  of 
the  *'.MOD”  versions  of  these  files  (see  the  discussion  of  Queries  9  and  10  in 
Chapter  6). 
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FILE  PROCESSED  fSV  USRMSCTL 


EXHIBIT  A-1.  SPECIAL  SUPPLY  CONTROL  FILE  PRINTOUT 


Rf450  0  SC  ORC  94  SPECIAL  SUPPLV  CONfROt  flt£  PRINtOtIt  DATE  27  f£B  88  PAGE  00413 


EXHIBIT  A-1.  SPECIAL  SUPPLY  CONTROL  FILE  PRINTOUT  (Continued) 


r 

N 

—NEW  PROCUREMENT  GROUPING  CODE  * 

PROC.gr. CD 

1672  MAX. NSN  3 

ITEM  NAME 

FSC  ICC  AOM.LT  STANDARD. PRICE  MAX. MONTH 

SH1RT,NAN'S 

8405 

P  195 

7.25 

36 

MSN  NIIN 

PRO.LT 

VIP(1*Y) 

FIX. SAFE 

QFD 

1  010772955 

255 

1 

4.5 

6 

2  010772957 

255 

1 

4.5 

105 

3  010772959 

255 

1 

4.5 

444 

NSN  MAO  OWRMRP  ALPHA 

ARS 

PER.RTC. 

DEMAND 

1  296.0 

0 

0. 

21.0 

.1296 

2  2611.0 

0 

0. 

76.0 

.4661 

3  5166.0 

0 

0. 

94.0 

.4185 

NSN  1  NIIN 

010772955  CT 

REQUIREMENT 

MATRIX  FOR 

36  MONTHS 

410 

380 

415 

402 

417 

428 

420 

430 

431 

422 

419 

411 

410 

421 

416 

404 

422 

430 

420 

432 

432 

421 

407 

401 

411 

410 

406 

404 

408 

418 

422 

422  ' 

421 

424 

424 

424 

NSN  2  NIIN 

010772957  CT 

REQUIREMENT 

MATRIX  FOR 

36  MONTHS 

nv/ciAa«9«  ^  ~ 

5791 

6147 

6104 

5432 

6289 

6791 

6375 

6948 

6979 

6424 

6233 

5843 

5791 

6378 

6118 

5448 

6417 

6847 

6364 

7031 

7003 

6366 

5592 

5275 

5861 

5807 

5564 

5461 

5704 

6263 

6476 

6433 

6407 

6551 

6551 

6551 

NSN  3  NIIN 

010772959  CT 

REQUIREMENT 

MATRIX  FOR 

36  MONTHS 

sssMsa 

urnffunc  •  1  . 

2 

HwCV  A  Q9  •  X 

0 

13365 

13923 

14009 

12626 

14389 

15419 

14564 

15742 

15808 

14668 

14277 

13474 

13365 

14515 

14041 

12660 

14653 

15539 

14544 

15912 

15856 

14548 

12958 

12304 

13509 

13401 

12899 

12687 

13185 

14335 

14772 

14681 

14630 

I49Z7 

14927 

14927 

END.OF.PGC  1672  PGC  QRQMT  000 

PGC  QD 

000 

%A/R  0 

EXHIBIT  A-2.  SSCF  INPUT  FILE 
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A-6 


EXHIBIT  A-3.  MANAGEMENT  POLICY  TABLE  11 


Itliltittiiiitttllittliilttttllitllltitittlittlititttttitttill 
ittitttliiittt  ALTERNATIVE  ASSUMPTION  FILE  tttttttiltlltttttt 
ttliitiIttitllltMttttIttitItttiiltftllHttttItttttItttttttttt 

**************  procurement  cycle  data  ************************ 

T  Ml  M2 

365  925  9999 


************  OVERRIDE  TRACES  AMD  OPTIONS  **************** 

TRACES  AND  OPTIONS:  1  >  TRUE  and  0  -  FALSE 

0  TRACE17:  if  1  (TRUE)  will  print  the  values  read  in  from  the 
SSCF  file  to  the  output  file,  DLAOUT.DAT  ,  if  0  will  not. 

0  DO  REQUISTIOM  OPTION: if  1  will  have  requisition  and  recruit  info 
generated,  if  0  will  treat  daily  demand  as  the  requisition  size 


EXHIBIT  A-4.  ALTERNATIVE  ASSUMPTION  FILE 


EXHIBIT  A-5.  REQUISITION  SIZE  RATIO  DISTRIBUTION 
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APPENDIX  B 


OUTPUT  DATA 


AGGREGATE  PROCUREMENT  GROUPING  CODE  (PGC)  REPORT 

aassssaasasxaaaaaaaaaaaaa  AGGREGATE  PGC  REPORT  aaaaaaaaaaaaaaaaaaaaaaaaaaaa 

3  PGC  RESULTS  IN  SUMMARY  (FILE  ALLPGCS.OAT) 


aaaaAVERAGE  — 

■■%REQT»» 

a.aaSTOCK  LEVELS^ 

aaaa 

aaass 

DEMAND- 

aaaaaaaa 

PGC 

BOB 

SUP 

AVAIL 

($ 

1,000,000  ) 

UNIT 

REQT 

RTC  REQT 

/ID 

UNIT 

REQT 

ALL 

RTC 

ONHAND 

ONORDER  SAFETY 

AMD/lOO 

AMD 

AMO 

1834 

1853 

106 

96 

97 

88 

132 

54 

740 

1220 

38 

1765 

282 

38 

99 

98 

119 

189 

69 

224 

1864 

96 

1672 

751 

11 

97 

97 

10 

25 

7 

211 

257 

15 

TOTAL 

2886 

155 

98 

98 

217 

346 

130 

1175 

3341 

149 

KEY:  AMD 

RBQT 
ALL 
RTC 
BOH 
SUP  AVAIL 


>  AVERAGE  MOHTHLY  OEMAMD 

-  REQUISITIONS 

-  ALL  CUSTOMERS  (PICS) 

-  RECRUIT  TRAINING  CENTERS 
«  BACKORDERS  ON  HAND 

-  SUPPLY  AVAILABILITY 


LONG-DURATION  TRACE  OUTPUT 

ttttiltitittittttitittittitttItIttfiilfiiMttittttItIttIttittttttttttt 
ttttItfIMtt  the  detail  TRACE  OUTPUT  REPORT  Mttf tttf ttlf «l«i« 

tttlMfittlittMttittt(FILE:  OLAOUT.OAT)il«tltliltltttttttttittttttlil 

(ID  NUMBER  OF  RUM  0) 


INPUT  DATA 


aaaaaaaaaaaaa.  MANAGEMENT  POLICY  TABLE  II  FILE  INPUT  aaaaaaaaaaaaaa 
PGC  1672  METHOD  OF  DELIVERY  4  PGC  FIRST  DELIVERY  DAYS  165 


X  « 

5» 

Z  -  1%  MINIMUM 

PROC 

MONTH 

a 

1 

DELIVERY . PERCENT 

15 

MONTH 

a 

2 

DELIVERY . PERCENT 

15 

MONTH 

a 

3 

DELIVERY. PERCENT 

20 

»K>NTH 

a 

4 

DELIVERY. PERCENT 

20 

MONTH 

a 

5 

DELIVERY . PERCENT 

15 

MONTH 

a 

6 

DELIVERY . PERCENT 

15 

B-1 


PGC  SPECIAL  SUPPLY  CONTROL  FILE  INPUT  DATA  »>»»»> 


PROC.GR.CD  1672  NUMBER  OF  NSN 


EM  NAME 
SHIRT, MAN'S 
NUN 

010772955 

010772957 

010772959 


FSC  ICC  AOM.LT  STANDARD. PRICE  MAX. MONTH 


8405 

PRO.LT 

255 

255 

255 


P  195 
VIP(1=Y) 
1 
1 
1 


7.25 

FIX. SAFE 
4.5 
4.5 
4.5 


OWRMRP  ALPHA 


PER. RTC. DEMAND 
296 
661 
185 


SIMULATION  DATA  DESCRIPTION 


DELIVERY  MATRIX  FOR  X,  Y,  AMO  Z  ITEMS 
XYZ  1  2  3  4  5  6  !  SUM% 

1  .150  .150  .200  .200  .150  .150  !  96.41 

2  .150  .150  .200  .200  .150  .150  !  3.59 

3  0.  0.  0.  0.  0.  •l•l.E•»-014  i  .00 

SUMMARY  OF  MONTHLY  TOTAL  FORECAST  AND  CST  36  MONTH  POI  FORECASTS 
SN  TOTAL  AMF  POI  AMF  POI  STD  %  POI  STD/POI  AMF 

1  419  417  10.7  3 

2  6247  6212  482.0  8 

3  14371  14223  991.0  7 


.........  model  option  assumptions  (true-1  and  false»0)  »»=ax..=.== 

1) PGC  NUMBER  1672 

2) SIMULATED  DEMAND  KNOB  1.00  (0:FALSE  »  DEMAND  IS  FORECAST , else  MAD) 

3) PLT  OATS  DELAYED  KNOB  1.00  (0:FALSEa  Constant  PLT,  else  variance) 

4) SHORT  RUN  WITH  PLOT  0  ( 0 : FALSExlonger  run  for  definitive  results) 

5) LEMTH  OF  SIMULATION  100  TOTAL  LENGTH  OF  RUN  WITH  WARMUP  105 

6)  2:  0  DO  NOT  ADD;  Inruns  for  same  PGC(10  ^  1ST  PGC  in  group); 

2«add  different  PGC  info  (20  «  1ST  PGC  -in  group) 

8)  VARIABLE  SAFETY  LEVEL  OPTION  0  (0: FALSE-  FIXED  SAFETY  LEVEL) 

9) EDITED  THE  SSCF  DATA  0  (0:FALSE-  use  standard  data  with  no  change) 

10) EDITED  MPTOll  TABLE  0  (OzFALSE-  use  standard  data  with  no  change) 

11) EDITED  ASSUMPTIONS  0  (0:FALSE  -  standard  assumptions,  no  change) 

O  DAILY  DEMAND  RATE  FROM  POISSON  DIST.  0  ( 0 : FALSE-MONTHLY  OEMAMD/30) 
o  REQUISITION  GROUPINGS  FOR  DEMANDS  1  (0:FALSE-REQ.SIZE-DDR  each  day) 
o  SIMULATED  DEMAND  via  MAPE  0  (0: FALSE  -MO  adjustments  used) 

o  NORMAL  CTREQ  DISTRIBUTION  1  (OiFALSE-  1ST  3yrs.  are  actual  CTREQ) 
o  COVARIANCE  FOR  ALL  MSNs  0  (0:FALSE-  only  PGC  covar  calculated) 


KEY  VARIABLES  USED  IH  RUR 


ALT  195 

PLT 

OF  FIRST  DELIVERY 

165 

COST  $  7 . 

25 

Ml  925. 

0 

M2  9999.0 

T 

365 

NSN 

RTC  CUT 

ARS 

%RTC  STOCK 

OWRM 

PLT 

SAFETY  MTHS 

%SD/AMF  VIP 

XYZ 

1 

342 

21 

13  8107 

0 

255.0 

4.500 

88.4  1 

2 

2 

200 

76 

47  120199 

0 

255.0 

4.500 

52.2  1 

1 

3 

293 

94 

42  276413 

0 

255.0 

4.500 

44.9  1 

1 

SIMULATIOM  OVER  TIME 


END  OF  WARMUP  PERIOD:  RESET  VARIABLES:  TIME.V  1800  AT. MONTH  60 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 


BEGINNING  OF  MONTH  1  C  &  T  LEVELS  &  DEMANDS  BY  NSN  (time.v  1800) 


NSN 

3Qx00R 

FORCTS  PCP.MTH 

MIN. PC 

ROP  QTY  STOCK  ORDER  UBO 

RBO 

1 

656 

417 

11.0 

6.0 

8238  6639 

3938  0 

0 

2 

7695 

6020 

6.0 

6.0  118268  54468 

88867  0 

0 

3 

12503 

13780 

6.0 

6.0  290497  106432 

239339  0 

0 

QUICK 

NSN 

1 

YR 

16.0 

MEAN 

1 

METSTOCK 

17877 

Cl 

1 

%CI/AVE 

168 

QUICK 

NSN 

1 

YR 

18.0 

MEAN 

0 

METSTOCK 

139379 

Cl 

1 

%CI/AVE 

171 

QUICK 

NSN 

1 

YR 

20.0 

MEAN 

0 

NETSTOCK 

155878 

Cl 

1 

%CI/AVE 

174 

QUICK 

MSN 

1 

YR 

22.0 

MEAN 

0 

METSTOCK 

110991 

Cl 

1 

%CI/AVE 

176 

QUICK 

NSN 

1 

YR 

24.0 

MEAN 

2 

NETSTOCK 

141788 

Cl 

2 

%CI/AVE 

137 

QUICK 

NSN 

1 

YR 

26.0 

MEAN 

2 

NETSTOCK 

179107 

Cl 

2 

%CI/AVE 

139 

QUICK 

NSN 

1 

YR 

28.0 

MEAN 

1 

NETSTOCK 

200079 

Cl 

2 

%CI/AVE 

140 

QUICK 

MSN 

1 

YR 

30.0 

MEAN 

1 

NETSTOCK 

178413 

Cl 

2 

%C1/AVE 

141 

QUICK 

NSN 

1 

YR 

32.0 

MEAN 

1 

NETSTOCK 

144105 

Cl 

2 

%CI/AVE 

143 

QUICK 

MSN 

1 

YR 

34.0 

MEAN 

7 

NETSTOCK 

-31023 

Cl 

10 

%CI/AVE 

149 

QUICK 

MSN 

1 

YR 

36.0 

MEAN 

7 

NETSTOCK 

173541 

Cl 

10 

%CI/AVE 

150 

QUICK 

NSN 

1 

YR 

38.0 

MEAN 

6 

NETSTOCK 

64575 

Cl 

9 

%CI/AVE 

151 

QUICK 

NSN 

1 

YR 

40.0 

MEAN 

6 

NETSTOCK 

146930 

Cl 

9 

%CI/AVE 

151 

QUICK 

NSN 

1 

YR 

42.0 

MEAN 

20 

NETSTOCK 

128760 

Cl 

20 

%CI/AVE 

100 

QUICK 

MSN 

1 

YR 

44.0 

MEAN 

19 

NETSTOCK 

192819 

Cl 

25 

%CI/AVE 

134 

QUICK 

MSN 

1 

YR 

46.0 

MEAN 

22 

NETSTOCK 

-8975 

Cl 

24 

%CI/AVE 

110 

QUICK 

NSN 

1 

YR 

48.0 

MEAN 

22 

NETSTOCK 

84369 

Cl 

23 

%CI/AVE 

105 

END  OF  MONTH  DATA:  MONTH  600  YEAR  '  50.0  (time.v  19800) 


-CUMMULATIVE- 

>AMF-> 

RATIO 

-»»«AVE 

UNITS— 

»«AVE  MONTHS— 

MSN 

ARS.SM 

INTRVL 

FORCST 

FOR/DD 

ONORDER 

ONHAND 

%0/0 

OR/F  OH/F  WAR 

1 

22.3 

1.5 

419 

90. 

71 

7591 

3599 

67.8 

18  9 

0. 

2 

75.8 

.4 

6256 

101. 

79 

100647 

43418 

69.9 

16  7 

0. 

3 

92.8 

.2 

14402 

96. 

46 

245858 

82358 

74.9 

17  6 

0. 

■■■REQUIS  J 

LTIONS*" 

■■•■UNIT 

U&fUUI  uo******» 

>»AVBOD— 

--■DEM/YR- 

■  «  a- 

— AVBOD- 

■  ««« 

saaaDEM/YR>>>> 

NSN 

TOT 

RTC 

TOT 

RTC  TOT 

RTC 

TOT 

RTC 

1 

66.2 

68.1 

248 

.1 

1.7 

68.6 

69.4 

5538 

888 

2 

77.7 

69.9 

973 

.6 

70.7 

74.4 

65.7 

73758 

33955 

3 

22.8 

22.6 

1930 

.2 

106.3 

23.0 

22.6 

179164 

73053 
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— requisit: 

EB08->»« 

COHS»*"> 

-■FILL 

RATES— 

■■■EBOs-——-- 

IDS** *■“»****■ 
*«F1LL  EUITES* 

NSM 

TOT 

RTC 

TOT 

RTC 

TOT 

RTC 

TOT  RTC 

1 

2.8 

.04 

93.8 

88.10 

64.9 

17.13 

93.9  89.99 

2 

10.7 

.59 

94.9 

95.73 

674.2 

227.62 

95.6  96.32 

3 

7.3 

.42 

94.0 

93.68 

700.2 

287.05 

93.9  93.75 

QUICK 

MSN 

1  YR  50.0 

MEAN 

22  NETSTOCX 

117664  Cl 

23  %CI/AVE  103 

BEGINNING 

OF 

MONTH 

601  C  &  ' 

r  LEVELS  & 

DEMANDS  1 

3Y  NSN  (tiine.vl9800) 

NSN 

30XODR 

FORCTS  PCP.MTH 

MIN. PC 

ROP  QTY  i 

STOCK 

ORDER  UBO 

RBO 

1 

331 

419 

11.0 

6.0 

8120  4182 

6134  0 

0 

2 

6411 

6043 

6.0 

6.0  124692 

0  150004  1449 

30 

3 

7085 

14393 

6.0 

6.0  279536  114931  218251  0 

0 

QUICK 

NSN 

1 

YR 

52.0 

MEAN  21 

NETSTOCX 

128688 

Cl 

22 

8CI/AVE 

104 

QUICK 

NSN 

1 

YR 

54.0 

MEAN  21 

NETSTOCX 

155547 

Cl 

21 

%CI/AVE 

104 

QUICK 

NSN 

1 

YR 

56.0 

MEAN  20 

NETSTOCX 

116591 

Cl 

21 

%C1/AVE 

105 

QUICK 

NSN 

1 

YR 

58.0 

MEAN  19 

NETSTOCX 

95937 

Cl 

20 

%CI/AVE 

105 

QUICK 

NSN 

1 

YR 

60.0 

MEAN  18 

NETSTOCX 

158045 

Cl 

20 

%CI/AVE 

106 

QUICK 

NSN 

1 

YR 

62.0 

MEAN  18 

NETSTOCX 

160034 

Cl 

19 

%CI/AVE 

106 

QUICK 

NSN 

1 

YR 

64.0 

MEAN  17 

NETSTOCX 

206881 

Cl 

18 

%CI/AVE 

107 

QUICK 

NSN 

1 

YR 

66.0 

MEAN  17 

NETSTOCX 

141583 

Cl 

18 

%CI/AVE 

107 

QUICK 

NSN 

1 

YR 

68.0 

MEAN  16 

NETSTOCX 

230821 

Cl 

18 

%C1/AVE 

107 

QUICK 

NSN 

1 

YR 

70.0 

MEAN  16 

NETSTOCX 

223361 

Cl 

17 

%CI/AVE 

108 

QUICK 

NSN 

1 

YR 

72.0 

MEAN  15 

NETSTOCK 

56696 

Cl 

17 

%CI/AVE 

108 

QUICK 

NSN 

1 

YR 

74.0 

MEAN  16 

NETSTOCK 

93476 

Cl 

16 

%CI/AVE 

104 

QUICK 

NSN 

1 

YR 

76.0 

MEAN  IS 

NETSTOCX 

162234 

Cl 

16 

%CI/AVE 

104 

QUICK 

NSN 

1 

YR 

78.0 

MEAN  15 

NETSTOCK 

189017 

Cl 

15 

%CI/AVE 

104 

QUICK 

NSN 

1 

YR 

80.0 

MEAN  14 

NETSTOCK 

85966 

Cl 

15 

%CI/AVB 

104 

QUICK 

NSN 

1 

YR 

82.0 

MEAN  14 

NETSTOCK 

135080 

Cl 

15 

%CI/AVE 

105 

QUICK 

NSN 

1 

YR 

84.0 

MEAN  14 

NETSTOCK 

146384 

Cl 

14 

%CI/AVE 

105 

QUICK 

NSN 

1 

YR 

86.0 

MEAN  13 

NETSTOCK 

152325 

Cl 

14 

%CI/AVE 

105 

QUICK 

NSN 

1 

YR 

88.0 

MEAN  13 

NETSTOCK 

184939 

Cl 

14 

%CI/AVE 

105 

QUICK 

NSN 

1 

YR 

90.0 

MEAN  13 

NETSTOCX 

196828 

Cl 

14 

%CI/AVE 

106 

QUICK 

NSN 

1 

YR 

92.0 

MEAN  13 

NETSTOCK 

184640 

Cl 

13 

%CI/AVE 

104 

QUICK 

NSN 

1 

YR 

94.0 

MEAN  12 

NETSTOCK 

37787 

Cl 

13 

%CI/AVE 

104 

QUICK 

NSN 

1 

YR 

96.0 

MEAN  12 

NETSTOCK 

211727 

Cl 

13 

%CI/AVE 

105 

QUICK 

NSN 

1 

YR 

98.0 

MEAN  12 

NETSTOCK 

183423 

Cl 

12 

%CI/AVE 

105 

END  OF 

'  MONTH  DATA:  1 

MONTH  1200 

YEAR  100.0 

(time.v  37800) 

a 

■CUMMULATIVE-  -AMF--  RATIO  —aAVE  UNITS— 

a' 

■AVE  MONTHS— 

NSN  ARS.SM 

INTRVL  FORCST  FOR/DO  ONORDER  ONHAND 

%0/0 

OR/F  OH/F  WAR 

1 

21.9 

1. 

5 

419  93. 

04  7296 

3864- 

65.4 

17  9 

0. 

2 

76.0 

• 

4  1 

6246  101. 

57  99645 

43507 

69.6 

16  7 

0. 

3 

93.6 

• 

2  14347  98. 

73  234794 

92619 

71.7 

16  6 

0. 

_ 

' 

*KJS^ 

fuial  i  ■ 

il./l'IO  ******* 

U&MAJ 

Ni/O 

aa 

a 

■■-AVBOD“*» 

isaa 

— DEM/YR- 

aaaa  a 

— AVBOD- 

aaaa 

a: 

— DEM/YR 

aaaa 

NSN 

TOT 

RTC 

TOT 

RTC 

TOT 

RTC 

TOT 

RTC 

1 

63.8 

68.1 

246.3 

1.6 

66.7 

69.4 

5400 

858 

2 

61.1 

55.1 

971.1 

71.2 

57.4 

49.1 

73789 

34160 

3 

22.7 

22.5 

1862.9 

104.1 

22.9 

22.6 

174371 

72132 

mmmmm 

■REQUISITIONS—— 

aaaa  a 

a=a=-UNIT 

DEMANDS 

aaaaaaaaa 

aa 

a 

EBOs-- 

:aaa 

■■FILL  RATES=-  a*aEBOs»»» 

aa 

aa 

FILL  RATES^ 

NSN 

TOT 

RTC 

TOT 

RTC 

TOT  1 

RTC 

TOT  RTC 
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1.4 

.02 

96.7 

93.83 

32.8 

8.57 

96.7 

94.82 

5.8 

.32 

96.5 

97.03 

367.6 

126.35 

96.9 

97.29 

3.7 

.21 

96.9 

96.75 

350.3 

143.60 

96.8 

96.83 

NSN 

1 

LAG 

1 

COVAR 

1440.9 

COVAR. SUM 

2867.36 

CORR 

.2547 

MSN 

1 

LAG 

2 

COVAR 

-101.8 

COVAR. SUM 

2665.81 

CORR 

-.0180 

MSN 

1 

LAG 

3 

COVAR 

-127.8 

COVAR. SUM 

2414.10 

CORR 

-.0226 

MSN 

1 

LAG 

4 

COVAR 

-142.2 

COVAR. SUM 

2135.33 

CORR 

-.0251 

NSN 

1 

LAG 

5 

COVAR 

-139.9 

COVAR. SUM 

2135.33 

CORR 

-.0247 

NSN 

1 

LAG 

6 

COVAR 

-119.4 

COVAR. SUM 

2135.33 

CORR 

-.0211 

SUMMARY 

NSN 

1 

COVAR/N2  2135. 

3  VAR  5657.6  MEAN 

f  11.690 

STATS  FOR  RUM:  M.LAGS  4  IMTVL  180  BLOCKS  200  TRs  100.0 

MSM  MEAN  VAR  2COVAR/M  MEAN. VAR  C.I.95%  «C.I./MEAM 

1  12  5657.6  2135.3  39.0  12  104.66 

QUICK  MSN  1  YR  100.0  MEAN  12  NETSTOCK  129667  Cl  12  %CI/AVE  105 


SUMMARY  PGC  REPORT 

.....................(PGC  HO.  1672  RUN  ID  0 ) 

PGC  NAME  SHIRT, MAM'S  NSNs  3  COST  7.25  ORDERS/YR  2.24 


mmmmmmmmMwmmm  TIME  WGHT  BO  »»—  AVAILABILITY  «  —  « «  DEMAMDS/YR  « 
TOT  RTC  TOT  RTC  TOT  RTC 

REQUISIT.  10.9  .6  96.75  96.84  3080  177 

UNITS  750.7  278.5  96.85  96.96  253560  107150 


AVERAGE:  STOCK  *«■«■  ONORDER  *  SAFETY  LEVEL  — »■ 

UNITS  139991  341734  94664 

DOLLARS  1014932  2477570  686311 

CALIBRATIONAALIDATION  INFORMATION 

TIME.V(YR)  105.0  SIM  (YRS)  100.0  WARMUP  5  (REVIEW  2  DEMAND  1  DAYS) 
PGC. BO  %CIAEAN  AVE  NET  STOCK  %OR/OH-K}R  %  FORE/DEMD  YR  FORCST 
12  104.66  139465  70.94  99.44  252136 


■■■■AVERAGK»=  ■■%REQT»*  ■■■■STOCK  LEVELS^^^**  ■■■■■dEMAND^^*»^=^^= 
PGC  BOH  SUP  AVAIL  OMHAMD  ONORDER  SAFETY  UNIT  REQT  RTC  REQT 

/ID  UNIT  REQT  ALL  RTC  ($  100,000)  AMD/100  AMD  AMO 

1672  751  11  97  97  10  25  7  211  257  15 
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EXHIBIT  B-1.  PGC  NET  STOCK  HISTOGRAM 


APPENDIX  C 


THE  DLA  DATA  CAPTURE  PROGRAM 

This  appendix  describes  the  steps  involved  in  the  clothing  and  textiles  (C&T) 
simulation  system  for  obtaining  Special  Supply  Control  File  (SSCF)  input  data  from 
the  Defense  Logistics  Agency  (DLA)  Standard  Automated  Materiel  Management 
System  (SAMMS).  We  discuss  the  requirement  to  download  this  information  to  a 
personal  computer  (PC)  and  to  run  the  "capture”  program,  which  converts  raw 
SAMMS  SSCF  data  into  a  smaller  SSCF  input  file  for  the  simulation.  The  steps 
described  here  are  necessary  before  any  simulation  runs  can  be  performed.  They 
need  only  be  performed  once  for  each  Procurement  Grouping  Code  (PGC),  and 
multiple  PGCs  may  be  processed  at  the  same  time. 

The  capture  program  reads  a  downloaded  SAMMS  file,  extracts  the 
information  required  by  the  simulation,  and  stores  it  on  the  PC  hard  drive.  Once 
this  is  done,  the  large  SAMMS  data  file  can  be  deleted  to  save  storage  space  on  the 
PC.  There  are  three  basic  steps  to  perform  the  capture  process. 

The  first  step  is  to  submit  a  request  to  SAMMS  for  SSCF  reports  to  be 
generated.  The  request  requires  that  all  national  stock  numbers  (NSNs)  in  the  P(jrC 
to  be  simulated  are  entered  and  that  all  NSNs  within  the  PGC  have  the  same  PGC 
number.  The  user  can  enter  NSNs  from  as  many  PGCs  as  desired,  but  the  request 
must  group  NSNs  by  PGC.  The  user  must  also  specify  that  the  output  medium 
should  be  a  file  on  the  mainframe,  not  a  hard  copy.  (SSCF  reports  are  normally 
produced  in  SAMMS  in  hard  copy.) 

The  second  step  is  to  download  the  file  of  raw  SSCF  reports  from  the  mainframe 
to  a  PC  —  either  to  the  hard  drive  (preferable)  or  to  floppy  disks.  This  can  be 
accomplished  with  a  direct  telecommunications  link  between  the  PC  and  the 
mainframe  or  through  the  use  of  an  intermediate  device  (e.g.,  a  minicomputer  or 
tape  reader)  able  to  receive  a  copy  of  the  mainframe  file  and  download  it  to  a  PC. 
Whatever  the  case,  the  SAMMS  file  of  SSCF  reports  must  be  stored  in  a  file  called 
C:\SIM\DLADATA\SSCFTAPE  on  the  PC. 
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The  third  and  final  step  is  to  run  the  capture  program  and  produce  the  Hie 
C:\SIM\DLA\SSCFSIM.DAT  for  the  simulation  to  use.  Results  of  a  current  run  of  the 
"capture”  program  will  overwrite  the  contents  of  this  file  from  previous  runs.  To 
save  previously  captured  data,  capture  output  should  be  copied  to  an  alternative  file 
name.  The  "capture”  program  can  then  be  nm  to  create  a  new  SSCF  for  the  next 
PGC.  If  desired,  captured  files  for  different  PGCs  can  be  concatenated  to  form  one 
SSCFSIM.DAT  file,  which  can  contain  SSCF  data  for  more  than  one  PGC. 

The  screens  that  follow  show  the  step-by-step  process  (user  input  underlined) 
required  to  run  the  "capture”  program. 


EXHIBIT  C-1.  RUNNING  THE  CAPTURE  PROGRAM 


The  first  command  (Exhibit  C-1)  changes  the  directory  from  the  root  to  the 
SIMSCRIPT  directory,  the  second  command  calls  the  SIMLAB  software  of 
SIMSCRIPT,  the  third  command  accesses  the  DLADATA  capture  program,  and  the 
final  command  runs  the  capture  program.  Next,  .the  following  information  will 
appear  on  the  monitor; 
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THIS  PROGRAM  CAPTURES  THE  DATA  FRCM  THE  SPECIAL  SUPPLY  CONTROL 
FILE  (SSCF)  REPORT.  THE  SSCF  REPORT  FILE  MUST  BE  STORED  IN: 

C :  \S IM\DLA0ATA\SSCFTAPE 
FOR  THE  CAPTURE  PROGRAM  TO  RUM  PROPERLY 

THE  OUTPUT  OF  THIS  PROGRAM  GOES  DIRECTLY  TO  THE  SIMULATION 
MODEL  DIRECTORY,  TO  BE  INCORPORATED  AUT(»IATICALLY  WHEN  THE 
SIMULATION  RUNS.  THAT  OUTPUT  FILE  IS: 

C :  \S  IM\0LA\SSCFS IM . OAT 

important  MOTE:  <— — 

RUNNING  THIS  PROGRAM  WILL  OVERWRITE  THE  EXISTING  DATA  IM  THE 
SSCFSIM.DAT  FILE  WITH  NEW  DATA.  IF  YOU  HAVE  MOT  BACKED  UP  THE 
CURRENT  CONTENTS  OF  SSCFSIM.DAT  OR  WANT  TO  READ  CHAPTER  2  OF 
THE  DOCUMENTATION  FOR  FURTHER  EXPLANATION 


PRESS:  CTRL-C 

(TO  STOP  THIS  CAPTURE  PROGRAM  ) 


EXHIBIT  C-2.  CAPTURE  FILE  MAINTENANCE  INFORMATION 


The  screen  in  Exhibit  C-2  repeats  the  aspects  of  the  capture  process  just 
discussed.  Note  that  the  ''capture”  program  can  be  interupted  and  stopped  by 
striking  the  "CTRL”  and  ”C”  keys  simultaneously. 


C-3 


APPENDIX  D 


THE  C&T  VARIABLE  SAFETY  LEVEL  MODEL 

INTRODUCTION 

This  appendix  describes  the  Clothing  and  Textiles  (C&T)  Variable  Safety  Level 
(VSL)  model:  what  the  model  is,  what  it  does,  its  output,  and  the  connection  between 
the  VSL  model  and  the  C&T  simulation. 

The  VSL  model  is  an  anal)rtical  inventory  model.  The  mathematics  in  the  C&T 
VSL  model  is  the  same  as  that  in  the  Standard  Automated  Materiel  Management 
System  (SAMMS)  for  computing  VSLs  for  other  Defense  Logistics  Agency  (DLA) 
commodities.  The  C&T  VSL  model  allows  the  use  of  certain  variations  in  the 
standard  DLA  VSL  mathematics  to  accommodate  unique  C&T  characteristics.  The 
model  derives  the  amount  of  safety  stock  that  each  item  [national  stock  niunber 
(NSN)]  in  a  collection  or  system  of  items  should  receive  in  order  to  minimize  the  total 
number  of  time-weighted  backorders  in  the  system  for  a  given  investment  in  safety 
level.  The  system  of  items  may  be  the  NSNs  in  a  single,  multi-item  procure:  -ent 
grouping  code  (PGC)  or  the  collection  of  NSNs  in  a  group  of  different  PGCs. 

The  VSL  model  is  used  to  supplement  the  modeling  capabilities  of  the  C&T 
simulation.  It  produces  a  mix  of  safety  levels  for  the  system  of  items  it  processes. 
This  mix  takes  many  important  C&T  characteristics  into  account  to  compute  a 
'Tjest”  mix.  The  C&T  VSL  model,  however,  does  not  take  the  special,  multi-item 
reordering  features  of  a  multi-item  PGC  into  account.  The  simulation,  on  the  other 
hand,  considers  all  the  key  features  of  C&T  inventory  management,  including  the 
multi-item  reordering  feature.  It,  however,  cannot. determine  the  best  safety  level 
mix  for  the  system  of  items  being  simulated.  The  two  models  together  give  a  more 
complete  picture  of  C&T  safety  levels  and  system  backorders.  The  VSL  model 
computes  a  safety- level  mix,  and  the  simulation  estimates  the  number  of  backorders 
generated  with  that  mix.  Together,  the  two  models  allow  DLA  to  test  whether  the 
VSL  approach  at  C&T  will  lead  to  better  performance  than  that  achieved  with  fixed 
safety  levels. 
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At  present,  the  C&T  Directorate  uses  a  fixed  safety  level  for  most  of  its  NSNs. 
In  the  case  of  ”bag  items”  issued  to  recruits,  for  example,  fixed  safety  levels  are  set  by 
item  to  be  4.5  months  of  demand.  Fixed  safety  levels  only  consider  demand,  while 
VSL  calculations  take  other  factors  into  account  as  well.  The  simulation  can  test 
both  types  of  safety  levels  to  predict  which  safety  level  produces  better  system 
performance  (e.g.,  fewer  backorders). 

Since  comparing  fixed  safety  levels  with  VSLs  is  a  key  purpose  of  the  C&T 
simulation  system,  the  VSL  model  and  C&T  simulation  are  closely  connected.  Both 
models  use  the  same  data  bases,  the  same  leadtimes,  and  the  same  order  quantities. 
Users  can  use  VSL  model  results  in  the  simulation  (in  the  form  of  a  file  of  VSLs)  by 
responding  appropriately  in  the  query  session  at  the  beginning  of  a  simulation  run. 

The  SIMSCRIPT  source  code  for  the  VSL  model  appears  in  Volume  n  of  this 
report. 

ASSUMPTIONS  AND  EQUATIONS 


The  assumptions  and  key  equations  of  the  VSL  model  are  derived  from 
SAMMS  documentation  and  from  a  DLA  publication.  Review  of  SAMMS 
Requirements  Computations,  August  1985,  M.  K.Cyrus  et  al.,  p.  40. 

The  basic  SAMMS  equations  for  determining  the  safety  level  for  NSN  (i)  are: 

VSL.  =  SD  X  k.  (in  units) 

I  I 


SD  Xkj 

VSL.  =  (in  months) 

‘  AMF 

where: 


AMF  =  average  monthly  forecast, 

SD  =  standard  deviation  of  unit  demand  during  a  leadtime,  and 
ki  =  the  safety  level  factor  defined  by: 


k.  =  -0.70711n 


2.56  S.Q.aP 


ZE.^MADLT. 


C.MADLT 


exp(-1.13Q./MADLT.; 


[Eq.  D-2] 


[Eq.  D-3] 
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order  quantity  for  item  (i) 

mean  absolute  deviation  of  leadtime  demand  for  item  (i) 
essentiality  factor  for  item  (i) 
average  requisition  size  for  item  (i) 
unit  price  for  item  (i) 

on-hand  unit  backorders  for  the  system  (the  Beta  constraint) 

product  of  item  MADLT  and  cost,  summed  over  the  system  of 
items 

j  =  the  number  of  NSNs  in  the  system. 

To  adapt  the  SAMMS  VSL  equations  to  the  special  characteristics  of  C&T 
inventory  management,  the  order  quantity  (Q),  the  essentiality  factor  (ZE),  and  the 
average  requisition  size  (S)  elements  can  all  be  modified. 

The  Order  Quantity.  Q 

The  C&T  Directorate  has  expressed  the  concern  that  SAMMS  VSL  formulas  do 
not  account  for  incremental  deliveries.  To  adapt  the  SAMMS  VSL  formulas  for 
incremental  deliveries  (which  occur  naturally  under  Delivery  Methods  2,  3,  and  4), 
we  can  replace  the  value  for  order  quantity,  Q,  with  an  alternative  value  derived  as 
follows. 

The  order  quantity,  Q,  in  Equation  D-3  may  be  viewed  as  a  measure  of  average 
on-hand  stock.  In  particular,  in  a  standard  deterministic  system  with  constant 
demand  and  no  safety  level  or  backorders,  Q/2  equals  the  average  amount  of  stock  on 
hand.  This  holds  because  in  a  standard  system  order  quantities  are  delivered  in 
clumps.  If  order  quantities  are  delivered  incrementally,  the  average  amount  of  stock 
on  hand  changes  slightly.  Figure  D-1  illustrates  an  example. 

Figure  D-1  illustrates  the  on-hand  stock  profiles  over  time  of  an  NSN  with 
clumped  deliveries  (dashed  line)  and  incremental  deliveries  (solid  line)  under 
deterministic  conditions.  The  NSN  has  a  procurement  cycle  period  (PCP)  of 
12  months.  Under  incremental  deliveries,  the  NSN  has  six  deliveries  and  the  first 
delivery  is  3  months  early  (ME).  (With  incremental  deliveries,  a  portion  of  the  order 


where: 

Qi 

MADLTi 

ZEi 

Si 

Ci  = 

EcjMADLTj  = 
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quantity  is  delivered  early,  in  effect,  because  leadtimes  fall  in  the  middle  of 
incremental  delivery  schedules.)  Under  clumped  deliveries,  the  entire  order 
quantity  for  the  NSN  arrives  at  the  end  of  the  leadtime  (ME = 0).  Examination  of  the 
figure  shows  that  the  average  stock  on  hand  under  clumped  deliveries  is  6  months’ 
worth  of  demand,  but  is  6.5  months’  worth  with  the  incremental  delivery.  The 
average  on-hand  stock  for  any  delivery  scheme,  whether  incremental  or  not,  is  given 
by  Equation  D-4: 

Average  on  -  hand  stock  =  (  - - -  +  ME  j  X  AMF  *■ 

12 


On-hand 

Stock 

(in  months  ® 
of  demand) 


0 

Procurement  cycle  period  (PCP)  ■  1 2  months 

— — —  Clumped  deliveries:  average  stock  =  6  months  of  demand  (deliveries:  1;  months  early:  0) 

— —  Incremental  deliveries:  average  stock  «  6.5  months  of  demand  (deliveries:  6;  months  early:  3) 

FIG.  0-1.  ON-HAND  STOCK  UNDER  CLUMPED  vs  INCREMENTAL  DELIVERIES 

The  values  for  the  number  of  deliveries  and  months  early  depend  on  which 
matrix  delivery  method  applies  to  the  PCJC  and  whether  individual  NSNs  are  X,  Y, 
or  Z  items.  As  an  estimation  of  average  stock  on  hand,  the  formula  given  by 
Equation  D-4  works  for  all  four  methods  of  matrix  delivery  and  for  all  three  types  of 
items  (X,  Y,  or  Z). 
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The  C&T  VSL  model  allows  the  user  two  different  options  in  setting  a  value  for 
Q  in  the  VSL  formula  (Equation  D-3).  Under  the  incremental  delivery  option,  Q  is 
replaced  by  the  expression  in  Equation  D-4  times  two.  The  second  option  is  to  ignore 
incremental  deliveries  and  to  set  Q  to  be  the  computed  procurement  cycle  quantity. 

Deviation  in  Demand  Leadtime 


In  SAMMS,  the  MADLT  for  an  NSN  is  derived  using  the  following  general 
formula: 

MADLT.  =  [a  +  (b  X  leadtime)]  X  MAD., 
where  a  and  b  are  constants  based  on  the  alpha  factor  for  the  NSN. 

The  specific  formulas  for  demand  leadtime  are  as  follows: 

/  ALT  +  PLT.  X 

MADLT.  =  (  0.7  +  0.36  X  - -  X  MAD., 

‘V  30  /  * 

for  monthly  VIP  items  (C&T  alpha  factor  is  0.05),  and 

/  ALT  +  PLT.  X 

MADLT.  =  0.57  +  0.46  X  - — - -  X  MAD.,  tE*?- 

‘  \  90  /  ‘ 

for  quarterly  non- VIP  items  (C&T  alpha  factor  is  0.15). 
where: 

ALT  =  administrative  leadtime  in  days  (same  for  all  NSNs  in  PGC) 

PLTi  =  production  leadtime  in  days  for  the  speciHc  NSN,  based  on  the 
matrix  delivery  method  and  whether  the  NSN  is  an  X,  Y,  or  Z  item 

MADi  =  mean  absolute  deviation  in  demand  for  the  NSN  (measured  per 
month  for  VIP  items;  per  quarter  for  non- VIP  items). 

Item  Essentiality  (ZE) 

The  essentiality  factor,  ZE,  can  be  used  to  bias  the  VSL  equation  to  give  more 
"essentiar  items  greater  safety  level  (all  other  things  being  equal).  The  larger  the 
ZE  factor,  the  greater  the  protection.  In  practice,  DLA  has  not  used  the  essentiality 
factor  extensively,  setting  ZE  =  1  for  virtually  all  items. 


In  the  C&T  world,  those  items  demanded  by  Recruit  Training  Centers  (RTCs) 
are  considered  essential,  and  the  C&T  VSL  model  allows  RTC  customers  to  be  given 
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more  protection  through  the  use  of  the  essentiality  factor.  NSNs  with  a  larger 
percent  of  demand  from  RTCs  may  be  assigned  a  larger  ZE  factor  than  those  with 
smaller  RTC  demand.  When  the  essentiality  option  is  used,  the  essentiality  factor, 
ZE,  is  set  equal  to  the  RTC  demand  percentage  plus  0.5.  Under  that  option,  NSNs 
with  no  RTC  demand  are  assigned  a  ZE  factor  of  0.5  and  NSNs  that  have  a 
100  percent  of  their  demand  from  RTCs  are  assigned  a  ZE  factor  of  1.5.  The  other 
option  is  to  treat  all  NSNs  equally  by  assigning  them  a  ZE  factor  equal  to  1. 

Average  Requisition  Size,  S 

The  S  in  Equation  D-3  denotes  the  average  requisition  size  for  the  NSN.  When 
the  S  factor  is  used,  NSNs  with  larger  average  requisition  sizes  receive  less 
protection,  other  factors  being  equal.  For  C&T  items,  however,  since  RTCs  usually 
submit  the  largest  requisitions,  using  S  in  Equation  D-3  would  penalize  RTCs.  For 
that  reason,  the  C&T  VSL  model  treats  S  as  always  equal  to  1.0  in  Equation  D-2. 

Backorder  Goal,  p 

The  backorder  goal,  p  (beta),  is  entered  by  the  user  in  the  query  session  for  the 
C&T  VSL  model.  Beta  is  an  estimate  of  the  number  of  time-weighted  unit 
backorders  the  user  wishes  to  specify  as  the  backorder  constraint  for  the  system  of 
items  under  consideration.  In  practice.  Beta  usually  serves  as  a  control  knob  to 
adjust  the  VSL  model  to  meet  either  a  safety  level  investment  target  for  the  system 
or  a  supply  availability  rate  target.  The  use  of  beta  is  discussed  further  below. 

Constraints  on  VSL 

The  VSLi  defined  by  Equations  D-1  and  D-2  must  meet  two  constraints.  First, 
if  negative,  the  VSLi  is  set  to  zero.  Second,  VSLi  must  be  the  minimum  of  three 
values:  VSLi  as  computed,  three  standard  deviations  in  leadtime  demand,  and  mean 
leadtime  demand.  In  months,  the  VSL  is  the  minimi^  of: 

•  VSLi  =  [k(i)  X  MADLTi  X  1.25]  /  AMF 

•  VSLi  =  [  3  X  MADLTi  X  1.25  ]  /AMF 

•  VSLi  =  [PLTi  -H  ALT]  /30. 
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VSL  QUERY  SESSION 


Like  the  C&T  simulation,  the  C&T  VSL  model  starts  with  a  query  session. 
After  turning  the  PC  on,  the  user  performs  the  steps  shown  in  Exhibit  D-1. 

r  ^ 

;>CD\SIM  fRI 
C ; >\SIM>SIMLAB  fRI 
SiniLab>SBLECT  VSL  TRl 
SimLab>RlJH 


V _ J 

EXHIBIT  D-1.  STARTING  THE  C&T  VSL  MODEL 

The  first  step  in  Exhibit  D-1  changes  the  directory  from  the  root  to  the 
SIMSCRIPT  directory,  the  second  step  calls  the  Simlab  software  of  SIMSCRIPT,  the 
third  step  accesses  the  VSL  model,  and  the  fourth  step  runs  the  VSL  model.  If  the 
user  is  already  in  SimLab  (if  Steps  1  and  2  are  complete),  only  Steps  3  and  4  are 
required. 

r  ^ 

VSL  ASSUMPTIONS  a— 

1)  NO  PGC  BAS  MORE  THAN  200  NSNs 

2)  TOTAL  NUMBER  OF  NSNs  FOR  ALL  PGCs  IS  NO  MORE  THAN  300  NSNs 

3)  THE  MATRIX  DELIVERY  SCHEDULES  HAVE  INCONSISTENCIES  BETWEEN  THE 
ROP  PLT  AMO  THE  DELIVERY  PLT  THAT  MAKE  VSL  MODEL  RESULTS  LESS 
OPTIMAL  FOR  THE  FOLLOWING  CONDITIONS: 

-  IF  DELIVERY  METHOD  IS  |1 

-  IF  THE  NUMBER  OF  PGC  DELIVERIES  IS  GREATER  THAN  6 

4)  VIP  item  alpha  >.05,  non  VIP  item  alpha  >  .15  (or  a  &  b  factors 
are  .7  &  .36  for  VIP;  .57  6  .46  for  non  VIP,  respectively 

V _ ^ _ _ _ y 


EXHIBIT  D-2.  VSL  ASSUMPTIONS 
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Exhibit  D-2  is  the  first  screen  the  model  displays  once  the  C&T  VSL  model  is 
running.  The  screen  lists  the  key  assumptions  and  information  the  user  needs  to 
properly  run  the  model.  The  first  two  assumptions  are  programming  constraints  for 
the  model.  Assumption  1  is  that  no  single  PGC  has  more  than  200  NSNs.  This 
should  accommodate  all  C&T  PGCs.  The  next  assumption  addresses  the  system  of 
NSNs  for  which  VSL  values  are  to  be  computed.  The  model  can  estimate  a  safety 
level  across  a  single  PGC  or  a  number  of  PGCs.  If  the  user  is  calculating  a  VSL 
across  a  number  of  PGCs,  the  total  number  of  NSNs  cannot  be  greater  than  300.  If 
that  is  not  the  case.  Query  9  allows  the  user  to  increase  the  number. 

Assumptions  is  a  reminder  of  possible  disconnects  between  C&T  matrix 
delivery  schedules  and  the  assumptions  of  the  VSL  model.  The  matrix  delivery 
schedules  sometimes  contain  inconsistencies  between  the  production  leadtime  (PLT) 
used  for  reorder  point  (ROP)  calculations  and  the  PLT  used  for  actual  delivery.  For 
Method  1  deliveries,  and  when  there  are  more  than  six  delivery  periods,  ROP  and 
delivery  PLTs  may  disagree  by  several  months.  Under  these  conditions,  VSL-type 
safety  levels  are  less  likely  to  be  optimal. 

Assumption  4  reiterates  the  a  and  b  constants  used  in  the  VSL  calculations,  as 
described  in  Equations  D-5,  D-6,  and  D-7. 


f^)EMTER  till#  NUMBER  0  TO  5  FOR  THE  PGC  SELECTED  TO  RUK  ttlllltitttttttt 


NAME 

SERVICE 

MAX  NSN 

PGC  NUMBER 

0  - 

DEMO  PGC  (MAN'S  SHIRT) 

ARMY 

3 

1672 

1  - 

MAN'S  COAT 

ARMY 

65 

1765 

2  - 

WCMAN'S  SHIRT 

AIR  FORCE 

21 

1671 

3  - 

WCMfAN'S  SKIRT 

army 

80 

1748 

4  - 

MEN'S  SHOE 

ALL 

113 

1505 

5  - 

MEN  &  WOMEN  GLOVES 

ALL 

17 

1834 

6  -  WANT  TO  ENTER  AN  ALTERNATE  PGC  NUMBER 
99  -  FOR  ALL  PGCS  IN  THE  SSCF  report  (file  "SSCFSIM. OAT" ) 
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EXHIBIT  D-3.  VSL  QUERY  1 


Query  1  (Exhibit  D-3)  asks  the  user  to  enter  the  number  of  the  PGC  for  which 
VSL  values  are  to  be  computed.  The  query  lists  the  'Demo  PGC”  and  five  other 
PGCs  that  may  be  chosen.  If  any  of  those  PGCs  are  selected,  the  model  will 
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automatically  retrieve  the  required  SSCF  input  file,  prepared  by  the  "capture” 
program,  and  the  Management  Policy  Table  11  (MPTOll)  input  file.  If  the  user 
wishes  to  process  another  PGC  not  in  the  list,  a  "6”  should  be  entered.  This  option 
allows  the  calculation  of  VSLs  for  the  collection  of  items  within  a  single,  multi-item 
PGC.  If  the  user  wishes  to  perform  VSL  calculations  for  a  system  of  several  PGCs,  a 
"99"  should  be  entered.  This  option  computes  VSLs  for  a  collection  of  NSNs  across 
PGCs.  The  responses  "6”  and  "99”  both  generate  additional  screen  displays. 

la)  ENTER  THE  PGC  NUMBER  (NOTE:  BOTH  THE  SSCFSIM. OAT/MOD  AMD  THE 
MPTOll. OAT/MOO  FILES  MUST  ALREADY  HAVE  THIS  PGCS  DATA  WITHIN 

? 


\ J 


EXHIBIT  0*4.  VSL  QUERY  1a 


Query  la  (Exhibit  D-4)  appears  if  the  response  to  Query  1  is  "6”  (to  compute  the 
VSL  for  the  NSNs  in  one  PGC).  The  user  is  required  to  enter  the  PGC  number  of  an 
item  not  in  the  previous  list.  Query  la  allows  the  model  to  run  on  any  PGC  desired; 
however,  the  SSCF  input  file  prepared  by  the  "capture”  program,  and  the  MPTOll 
input  file,  must  have  been  produced  and  stored  in  the  files  named 
C:\SIM\DLA\SSCFSIM.DAT  and  C:\SIM\DLA\MPT01 1.DAT,  respectively. 

THE  ASSUMPTIONS  FOR  VSL  MODEL  WITH  MULTIPLE  PGCS: 

1)  ONLY  PGCs  FOR  VSL  IN  SSCF  "SSCFSIM. OAT” 

2)  THOSE  PGCs  ARE  ALSO  IN  MPTOll  FILE  (THOUGH  THE  MPTOll 
CAN  HAVE  PGCs  IN  DIFFERENT  ORDER  AMD  CAM  HAVE  PGCs 
NOT  INCLUDED  IN  THE  SSCF) 
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EXHIBIT  D-5.  VSL  ASSUMPTIONS  FOR  MULTIPLE  PGCs 
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Exhibit  D-5  is  the  screen  that  follows  Query  1  if  the  response  is  "99”  (to 
compute  VSL  values  for  the  NSNs  in  a  collection  of  PGCs).  It  lists  some  additional 
assumptions  of  a  VSL  for  multiple  PGCs.  The  first  assumption  is  a  reminder  that  all 
PGCs  represented  in  the  SSCF  data  will  be  processed  in  the  VSL  run.  The  second 
assumption  is  a  reminder  that  the  PGCs  contained  in  the  SSCF  must  also  have  the 
appropriate  data  in  the  MPTOll  file.  PGCs  may  appear  in  different  order  in  the 
MPTOll  file  than  in  the  SSCF  file,  and  the  MPTOll  file  is  allowed  to  contain 
additional  PGCs  not  represented  in  the  SSCF  data. 


EXHIBIT  0-6.  VSL  QUERY  2 


Query  2  (Exhibit  D-6)  allows  the  user  to  enter  the  backorder  goal  (Beta) 
described  earlier.  This  value  is  adjustable,  as  will  be  discussed  shortly. 


ENTER 


1 

0 


FOR  FURTHER  INPUT  SPECIFICATIONS  (QUERIES  4  TO  9) 
FOR  NO  FURTHER  CHANGE  AND  RUN 


EXHIBIT  D-7.  VSL  QUERY  3 


If  a  "1”  is  entered  for  Query  3  (Exhibit  D-7),  five  additional  queries  concerning 
optional  data  files,  maximum  number  of  NSNs,  and  model  assumptions  will  follow. 
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If  a  "0”  is  entered,  the  VSL  model  run  will  proceed  and  the  additional  queries  (4  to  9) 
will  not  appear. 

Queries  4,  5,  and  6  determine  what  input  files  are  used.  The  VSL  model  uses 
the  same  input  files  as  the  C&T  simulation.  The  user  should  be  sure  that  the  two 
models  are  using  the  same  inputs  and  that  the  responses  to  Queries  4, 5,  and  6  for  the 
VSL  run  are  the  same  as  those  to  Queries  9, 10,  and  11  for  the  simulation  run. 

4) ENTER  1  FOR  OPTIONAL  SCF  INPUT  DATA 

0  FOR  STANDARD  SCF  INPUT  DATA  [D] 

•> 
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EXHIBIT  0-8.  VSL  QUERY  4 

Query  4  (Exhibit  D-8)  allows  the  user  to  modify  any  of  the  input  SSCF  data.  To 
modify  the  SSCF  data,  the  user  must  first  edit  a  copy  of  the  file  named 
C:\SIM\DLA\SSCFSIM.MOD.  This  modification  is  done  before  running  the  VSL 
model.  Once  the  file  has  been  edited  and  saved,  the  VSL  model  can  be  run  and  ”1” 
entered  in  response  to  Query  4.  If  a  ”0”  is  entered,  the  VSL  model  uses  the  original 
(default)  SSCF  input  file  (C:\SIM\DLA\SSCFSIM.DAT). 

/  \ 

5) ENTER  I  FOR  OPTIONAL  MANAGEMENT  POLICY  TABLE  INPUT  DATA  (MPTOll) 

0  FOR  STANDARD  MANAGEMENT  POLICY  TABLE  INPUT  DATA  [D] 

? 
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EXHIBIT  0-9.  VSL  QUERY  5 
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Query  5  (Exhibit  D-9)  allows  the  user  to  modify  any  of  the  input  data  in  the 
MPTOll  file.  To  do  so,  the  user  must  first  edit  a  copy  of  the  MPTOll  table  in  the  file 
named  C:\SIM\DLA\MPT011.MOD.  This  modification  must  be  done  before  running 
the  VSL  model.  Once  the  file  has  been  edited  and  saved,  the  VSL  model  can  be  run 
and  a  ”1”  entered  in  response  to  Query  5.  If  a  "0”  is  entered,  the  VSL  model  uses  the 
original  (default)  MPTOll  input  file  (C;\SIM\D LA\MPT011.DAT). 

6)EHTER  1  FOR  OPTIONAL  ASSUMPTION  FILE:  M1,M2,T,  OPTIONS,  TRACES 
0  FOR  STANDARD  ASSUMPTIONS  [D] 

? 


V _ y 

EXHIBIT  0-10.  VSL  QUERY  6 

Query  6  (Exhibit  D-10)  allows  the  user  to  modify  model  data  inputs  and 
assumptions  not  contained  in  the  SSCF  and  MPTOll  files.  To  change  the  standard 
assiunptions,  the  user  must  first  modify  the  file  C:\SIM\DLiA\ASSUMP.MOD.  Once 
the  user  edits  and  saves  that  file,  the  model  can  be  run  and  a  "1”  entered  in  response 
to  Query  6.  If  "0”  is  entered,  the  default  assumptions  are  used. 


7)EMTER  I  FOR  ORDER  QUANTITY(a)  TO  CONSIDER  INCREMENTAL  DELIVERIES  [D] 
0  FOR  A  Q  EQUAL  TO  THE  PROCUREMENT  CYCLE  x  MONTHLY  FORECAST 

? 


EXHIBIT  0-11.  VSL  QUERY  7 


D-12 


Query?  (Exhibit D-11)  allows  the  user  to  select  one  of  the  two  methods  for 
calculating  order  quantities  (Q)  discussed  earlier.  If  a  ”1”  is  entered,  a  Q  that 
considers  incremental  deliveries  is  used  based  upon  the  matrix  delivery  method  and 
the  type  of  item.  If  a  ”0”  is  entered,  a  Q  that  assumes  clumped  deliveries  is  used  no 
matter  what  the  PGC  matrix  delivery  method  is. 


r 

8)EIITER  1  FOR  THE  ESSEHTIALITT  FACTOR  ZE  -  %  DEMAND  FOR  RTC  0.5 
0  FOR  NO  ESSENTIALITY  CONSIDERATIONS  OR  ZE  -  1  [D] 

? 
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EXHIBIT  D-12.  VSL  QUERY  8 
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Query  8  (Exhibit  D-12)  allows  the  user  to  select  one  of  two  options  for  the 
essentiality  factor,  ZE,  discussed  earlier.  If  a  ”1”  is  entered,  the  model  sets  the  ZE 
factor  equal  to  the  percent  of  RTC  demand  (expressed  as  a  fraction)  plus  0.5.  Under 
this  option,  ZE  will  have  a  possible  range  from  0.5  to  1.5.  If  a  "0”  is  entered,  the 
model  sets  the  ZE  factor  for  all  NSNs  to  1  (i.e.,  no  essentiality  weighting  scheme  is 
used). 

(  ^ 

9)ENTER  1  TO  CHANGE  MAXIMUM  NUMBER  OF  NSNs  IN  SYSTEM  (NOW  AT  300) 

0  TO  KEEP  MAX  NUMBER  AT  CURRENT  CEILING  VALUE  [D] 

(NOTE: FOR  MODEL  TO  ALLOCATE  ENOUGH  SPACE  THIS  VALUE  MUST  BE 

GREATER  THAN  OR  EQUAL  TO  THE  NO.  OF  NSNs  FOR  ALL  THE  PGCs) 

? 


V, 


EXHIBIT  0-13.  VSL  QUERY  9 


J 
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Query  9  (Exhibit  D- 13)  allows  the  user  to  increase  the  maximum  number  of 
NSNs  that  the  VSL  model  can  incorporate  into  its  calculations.  When  a  collection  of 
PCjCs  is  being  processed,  more  NSNs  may  be  involved  than  the  maximum  default 
value.  If  a  ”1”  is  entered,  the  default  value  can  be  changed  in  the  next  response;  if  a 
”0”  is  entered,  the  default  value  is  used.  The  maximum  number  of  NSNs  is  used  by 
SEMSCRIPT  to  allocate  computer  memory  space.  The  smaller  the  value,  the  faster 
the  model  runs.  However,  if  the  maximum  value  is  less  than  the  total  number  of 
NSNs  across  all  PGCs,  the  model  will  have  a  run-time  failure. 

9a) ENTER  THE  MAXIMUM  NUMBER  OF  NSMs  YOU  WAMT  INSTEAD ^ 


EXHIBIT  D-14.  VSL  QUERY  9a 


Query  9a  (Exhibit  D-14)  allows  the  user  to  enter  a  new  value  for  the  maximum 
number  of  NSNs. 


MMMmmmmmmm  MODEL  OPTION  ASSUMPTIONS  (tfue-l  and  £alse-0) 
o  ALL  PGCs  IN  SSCF  IN  SYSTEM  VSL  0(0:FALSE-  VSL  within  PGC  for  below) 

1) PGC  NUMBER  1672 

2) BETA  VALUE  FOR  FIRST  PASS  260 

4)  EDITED  THE  SSCF  DATA  0  (0:FALSE«  use  standard  data  with  no  change) 

5) EDITED  MPTOll  TABLE  0  (0:FALSE>  use  stan,dard  data  with  no  change) 

6) EDITED  ASSUMPTIONS  0  (0:FALSE  >  standard  assumptions,  no  change) 

7 )  INCREMENTAL  DELIVERY  Q  1  (0:FALSE-  Q  is  order  quantity) 

8)  ESSENTIALITY  FACTOR  ZE  1(0:FALSE  ZE  -  1,  else  ZE  «  %RTC  demand  +  0.5) 

9) MAXIMUM  SYSTEM  NSMs  300  MAXIMUM  NSNs  IN  ANY  PGC  200 
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EXHIBIT  0-15.  VSL  MODEL  SETTINGS 
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The  screen  in  Exhibit  D-15  appears  at  the  end  of  the  VSL  model  query  session. 
It  lists  the  responses  to  the  VSL  queries.  The  VSL  model  will  then  run,  unless  a 
”CTRL”  and  a  ”C”  are  pressed  simultaneously. 

FINAL  SUMMARY  RESULTS  FOR  THE  SYSTEM 
<BACXOROERS-EBO>  <AVA1LABIL1TY>  <COST  IN  1000  DOLLARS  >  DEMAND 
<BETA  MODEL>  <%  FILL  RATE  >  <  VSL  FSL  MAOLT  >AMF/1000 

260.00  283.34  99.353  972.  686.  357.  21. 

ENTER  NEW  BETA  (TO  STOP  ENTER  0)0 
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EXHIBIT  D-16.  C&T  VSL  MODEL  OUTPUT 


Once  the  model  has  run,  the  screen  in  Exhibit  D-16  appears.  It  displays 
aggregate  information  for  the  system  of  NSNs:  the  unit  backorder  goal  (beta);  an 
analytically  computed  estimate  for  time-weighted  unit  backorders;  the  demand- 
weighted  unit  supply  availability;  the  total  investment  in  variable  safety  level;  the 
investment  in  fixed  safety  level  (based  on  the  product  of  the  input  SSCF  values  for 
fixed  safety  level  in  months  times  AMF  times  unit  price);  the  product  of  cost  and 
MADLT  summed  over  all  NSNs;  and  the  average  monthly  demand  in  thousands  of 
units.  (The  beta  constraint  and  model-computed  expected  backorders  will  generally 
be  different  as  a  result  of  VSL  constraints.  They  will  agree  only  when  the  computed 
VSLi  value  applies  for  every  NSN  in  the  collection.  It  is  in  this  sense  that  the  beta 
constraint  is  a  control  knob.) 

At  this  point  in  the  model  run,  the  user  may  enter  a  new  beta  value  and  run  the 
model  again  to  reach  either  an  investment  target  or  a  performance  target.  For 
example,  the  model  can  be  used  to  develop  a  VSL  mix  in  which  the  total  investment 
in  VSL  equals  the  total  investment  in  fixed  safety  levels.  An  increase  in  beta  will 
cause  the  safety  level  investment  to  decrease;  a  decrease  in  beta  will  cause 
investment  to  increase.  With  a  small  number  of  iterations,  the  two  safety-level 
investments  can  be  made  to  agree.  The  user  may  also  adjust  beta  to  meet  a  system 
supply  availability  target  or  system  backorder  target.  For  each  new  beta  the  user 


D-15 


enters,  the  entire  VSL  equation  is  recalculated  and  the  table  in  Exhibit  D-16  is 
displayed.  Once  desired  results  are  achieved,  a  ”0”  may  be  entered  for  beta,  and  the 
iterative  process  will  stop.  The  entire  model  run  including  iterations  generally  takes 
no  longer  than  5  or  10  minutes,  even  for  a  large  number  of  NSNs  across  several 
PGCs. 


VSL  DATA  BY  PGC  AMD  MSN  IN  MONTHS 


P  PGC 


1765 

PGC  NAME 

COAT, MAM'S 

MSN 

VSL (MONTHS) 

KIIN 

1 

10.2950 

011056063 

2 

8.7782 

011056064 

3 

7.6373 

011056065 

65 

2.5100 

011056127 

1671 

PGC  NAME 

SH1RT,W(N(AN*S 

MSN 

VSL (MONTHS) 

MIIN 

66 

15.7000 

010676705 

67 

15.7000 

010676706 

68 

15.7000 

010676707 

• 

• 

• 

« 

• 

PGC  1  OUT  OF  5  SYSTEM  PGCs 
NSNs  WITHIN  PGC  65 


PGC  2  OUT  OF  5  SYSTEM  PGCs 
NSNs  WITHIN  PGC  21 


EXHIBIT  D-18.  VSL  OUTPUT  FILE  FOR  SIMULATION 


VSL  TRACE  INFORMATION 

Besides  the  file  of  VSL  values,  the  VSL  model  produces  a  trace  file  that  lists  the 
key  variables  calculated  for  each  NSN.  The  trace  information  is  stored  in  the  file 
C:\SIM\VSL\VSLOUT,DAT.  The  trace  information  also  includes  the  input 
information  from  the  SSCF  and  MPTOll  input  files.  The  trace  file  displays  the 
following  information  by  NSN  for  every  NSN  processed:  backorders,  supply 
availability,  MADLT,  k,  VSL  in  months,  demands  per  year,  cost,  order  quantity  (Q), 
and  essentiality  factor  (ZE). 
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APPENDIX  E 


DYNAMIC  GRAPHICS 


Computer  models  are  often  unused  or  misused  because  of  the  difficulty  in 
explaining  hundreds  of  lines  of  code  and  stacks  of  computer  output.  The  combination 
of  d)mamic  graphics  and  variable  switches  in  the  clothing  and  textiles  (C&T) 
simulation  offers  a  powerful  tool  for  presenting  simulation  results  in  understandable 
form  to  people  who  need  to  know  —  whether  they  are  programmers  who  must  check 
the  code,  users  who  must  learn  to  operate  the  model,  or  decision  makers  who  must 
act  on  its  results. 

This  appendix  describes  features  of  d3mamic  graphics  and  their  use.  It  also 
addresses  the  use  of  simple  switches  that  allow  key  variables  to  be  held  constant  or 
varied  over  time.  By  observing  the  effect  of  different  variables  dynamically  affecting 
the  system  over  time,  analysts  and  managers  can  better  understand  how  their 
system  —  and  their  simulation  —  works. 

FEATURES  OF  DYNAMIC  GRAPHICS 

Dynamic  graphics  are  available  with  most  personal  computer  (PC)-based 
simulation  packages.  The  C&T  simulation  is  programmed  in  PC  SEMSCRIPT  11.5, 
which  offers  dynamic  graphics  features. 

In  a  dynamic  graphic  plot,  information  is  plotted  as  the  model  actually  runs.  In 
presentations,  the  live  aspect  of  plotting  actual  results  over  simulated  time  gives  the 
model  more  credibility  and  interest  than  simply  showing  hard  copy  of  a  stationary 
plot  generated  earlier. 

Another  useful  feature  of  dynamic  plotting  is  the  automatic  adjustment  of  the 
time  axis,  which  yields  a  scrolling  effect  as  the  simulation  proceeds  in  time.  With 
scrolling,  it  is  possible  to  observe  30  years  of  simulated  activity  in  chunks  (e.g., 
3  years  at  a  time).  The  scrolling  feature  helps  in  identifying  important  events  that 
may  occur  only  rarely. 


Dynamic  graphics  in  PC  SIMSCRIPT  also  allow  the  user  to  change  the  speed  of 
a  plot,  plot  several  variables  on  the  same  set  of  axes,  generate  several  plots  with 
different  axes  on  the  same  screen,  or  display  several  virtual  screens  as  the 
simulation  runs. 

User  who  do  not  want  to  watch  a  long  simulation  can  capture  information  in  an 
external  process  file.  That  file  can  then  be  played  back  in  a  fast  forward  mode  that 
takes  only  seconds  to  read  and  plot.  (This  feature  can  be  added  to  the  C&T 
simulation  with  a  small  amount  of  additional  programming.) 

Graphics  software  in  PC  SIMSCRIPT  is  also  equipped  to  automatically  rescale 
the  vertical  axis,  as  the  dependent  variable  fluctuates  in  relative  si2e.  This  software 
eliminates  the  need  to  specify  the  bounds  of  a  plot  before  it  is  generated. 

Dynamic  graphics  is  sometimes  combined  with  simulation  animation,  which 
involves  the  use  of  icons,  pictures,  and  cartoon-like  effects.  Animation  effects  are  not 
included  in  the  C&T  simulation  system  at  this  time  primarily  because  d3mamic  plots 
are  sufficient  to  communicate  what  goes  on  in  the  simulation. 

Although  this  appendix  discusses  only  dynamic  graphic  plots,  other  dynamic 
graphics  —  histograms,  bar  charts,  pie  charts,  and  clocks  —  are  available  in  PC 
SIMSCRIPT. 

SWITCHES 

Even  with  dynamic  graphics,  a  plot  that  moves  randomly  up  and  down  on  the 
screen  may  give  little  insight  into  a  model.  To  help  isolate  the  effect  of  different 
variables,  the  C&T  simulation  has  ”switches”  that,  when  turned  off,  hold  pertinent 
variables  constant,  and  when  turned  on,  allow  variables  to  change  over  time  based 
on  given  distributions. 

Demand  and  leadtime  variables  are  the  key  random  variables  in  an  inventory 
system.  The  demand  variable  reflects  the  behavior  of  customers,  and  the  leadtime 
variable  reflects  the  behavior  of  suppliers.  The  two  key  switches  in  the  C&T  model 
are  for  demand  and  leadtime  variation. 


E-2 


EXAMPLE 


The  example  discussed  here  illustrates  dynamic  graphics  plotting  and  the  use 
of  switches.  We  use  actual  data  for  three  different  sizes  of  men’s  shirts,  labeled 
NSN 1,  NSN  2,  and  NSN  3  (NSN  =  National  Stock  Number). 

We  generate  dynamic  plots  of  the  net  stock  on  hand  over  time  for  each  shirt. 
We  illustrate  three  passes  of  the  model,  with  all  passes  identical  except  for  a  change 
in  switch  settings.  (In  particular,  the  second  and  third  passes,  in  which  variability  is 
introduced,  employ  the  same  random  seeds  as  the  Hrst  pass.)  For  those  passes,  none 
of  the  matrix  delivery  schedules  are  used  so  the  entire  order  is  received  at  one  time. 

First  Pass:  Deterministic  -  No  Variability 

Figure  E-1  is  a  snapshot  of  the  graphic  output  of  the  model  in  the  first  pass.  In 
this  pass,  customer  demand  equals  the  monthly  forecast  and  supplier  leadtimes  are 
constant  over  time.  The  horizontal  axis  denotes  time,  from  Day  1  to  Day  1,080 
(about  3  years).  The  vertical  axis  denotes  net  stock  on  hand  in  thousands  of  shirts. 
Positive  stock  represents  on-hand  inventory,  while  negative  stock  represents 
backorders  (unfilled,  outstanding  customer  demands). 


m  STOa 


MVS 

•  NSN  1  —  NSN  2  f  -  NSN  3 

FIG.  E-1.  FIRST  PASS:  DETERMINISTIC  -  NO  VARIABILITY 
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The  deterministic  pass  is  useful  for  observing  basic  features,  such  as  leadtime 
and  order  quantity.  On  Day  1,  a  replenishment  order  for  shirts  is  placed  with  a 
supplier.  (The  simulation  starts  with  on-hand  stocks  for  all  three  items  at  the 
reorder  point.)  The  entire  corresponding  shipment  arrives  a  leadtime  (450  days) 
later.  As  shown  in  Figure  E-1,  stocks  are  drawn  down  (demands  filled)  until  the  first 
replenishment  shipment  is  received  on  Day  450.  At  that  time,  stock  levels  for  all 
three  items  increase  by  an  order  quantity.  The  order  quantity  for  Army  men’s  shirts 
is  6  months  of  demand.  After  the  first  shipment  is  received,  the  6-month 
procurement  cycle  of  stock  is  drawn  down  and  the  next  shipment  arrives.  Repeating 
this  pattern,  we  obtain  the  familiar  sawtooth  curve  of  inventory  theory. 

Figure  E-1  also  illustrates  a  simple  example  of  a  warm-up  period  (the  time 
from  Day  1  to  Day  450),  as  well  as  steady-state  conditions  (from  Day  450  onward). 

Second  Pass:  Demand  Variability 

Figure  E-2  is  a  snapshot  of  the  second  pass  of  the  model,  with  all  variables  the 
same,  except  that  the  demand  variability  switch  has  been  activated.  As  shown  in 
Figure  E-2,  the  drawdown  of  stock  is  no  longer  linear.  Also,  orders  no  longer  arrive 
at  precise  6-month  intervals  (as  was  the  case  in  the  first  pass).  This  is  because 
reorder  points  are  being  reached  either  earlier  or  later  as  demands  vary.  [We  have 
not  yet  introduced  leadtime  variability,  however.  Once  placed,  orders  arrive  an 
exact  leadtime  (450  days)  after  being  ordered.] 

In  the  second  pass,  actual  demand  exceeds  forecasted  demand  by  enough  to 
cause  backorders  to  occur  in  the  third  year  of  simulated  time  (between  Day  720  and 
Day  1,080). 

Third  Pass:  Demand  and  Leadtime  Variability 

Figure  E-3  is  a  snapshot  of  the  third  pass.  This  pass  is  identical  to  the  second, 
except  that  the  leadtime  switch  has  now  been  activated.  With  variable  leadtimes, 
replenishment  shipments  from  suppliers  can  arrive  sooner  or  later  than  the  expected 
leadtime  of 450  days. 

As  shown  in  Figure  E-3,  the  first  two  shipments  arrive  later  than 
expected  —  on  Day  570  and  Day  810.  In  the  previous  pass,  these  two  shipments 
arrived  on  Day  450  and  Day  580,  respectively.  Because  of  these  delays,  stock  levels 
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FIG.  E-2.  SECOND  PASS:  DEMAND  VARIABIUTY 


Nn  STOCK 


MVS 

•  NSN  1  —  HSH  2  f  -  NSN  3 


FIG.  E-3.  THIRD  PASS:  DEMAND  AND  LEADTIME  VARIABIUTY 


are  insuf^cient  to  meet  demand  and  more  backorders  occur  than  in  the  previous 
pass. 

To  demonstrate  scrolling,  the  third  pass  of  the  model  run  lasts  an  additional 
year.  At  the  end  of  the  third  year,  the  model  readjusts  the  horizontal  time  axis, 
dropping  the  first  540  days  and  adding  an  additional  540  days  to  make  room  for  the 
fourth  year.  Figure  E-4  shows  final  results  after  the  model  has  scrolled  forward. 


tffil  STOCK 


FIG.  E-4.  THIRD  PASS  CONTINUED:  4-YEAR  RUN 


CONCLUSIONS 

The  features  and  flexibility  of  dynamic  plots  make  it  easy  to  observe  key 
variables  over  time  and  to  determine  whether  the  model  is  working  as  desired. 
Graphics  also  help  isolate  driving  conditions  for  further  examination.  With  dynamic 
graphics,  decision  makers  can  better  understand  important  simulation  features, 
such  as  the  warm-up  period,  variance,  and  the  meaning  of  steady-state  results.  They 
can  also  see  whether  the  key  aspects  of  their  business  have  been  incorporated  and 
are  correctly  modeled. 
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Once  the  user  is  satisfied  that  the  simulation  is  running  as  intended,  the 
dynanaic  graphics  feature  can  be  shut  off.  The  simulation  runs  approximately 
10  percent  faster  without  dynamic  graphics.  D3mamic  graphics  are  automatically 
shut  off  if  a  long  run  for  final  results  is  requested  in  the  query  session. 
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